[Kgdb-bugreport] Problem getting kgdb to read kernel symbols. addresses shifted?
warlord at MIT.EDU
Fri Sep 28 19:29:46 EDT 2007
ebiederm at xmission.com (Eric W. Biederman) writes:
> Pete/Piet Delaney <pete at bluelane.com> writes:
>> Jason Wessel wrote:
>> Shouldn't crash, kdump and kgdb take into consideration a
>> shift in the kernel so that gdb works normally?
>> Seems that having the kgdb stub knowledgeable of a shift
>> in the kernel might be easy to compensate for. Perhaps
>> just mapping all reads and writes that lie within the
>> original kernel segments to the shifted addresses.
> Good question.
> I remember hearing some oddball reports about something like this.
> My memory says what little tracking that happened pointed in
> the direction of a confused gdb.
Well, gdb agrees with System.map, so I'm sure that gdb itself is
okay. It's certainly possible that that the kgdb stub is weird,
but /proc/kallsyms doesn't match System.map, and THAT'S what's
confusing me most of all.
> In particular unless you deliberately run a kernel at a different
> address linux kernels should run at the addresses they were built
> for so there should be nothing that has to be done.
In my case I'm not doing anything special; the bzImage is definitely
built from the vmlinux, but the symbols are definitely offset.
Granted, I'm using the Fedora RPM build, so it's possible that THAT is
doing something weird. Unlikely, but possible. Using the
add-symbol-file seems to have mostly worked for me, and adding the
symbol file of my module seems to work, too.
Hopefully this will all get merged into the mainline sometime
soon and the gdb patches will get fed up into the gdb mainline
and everyone can be happy.. :)
> I'm running on foggy memories so something may have changed
> since last time I looked.
Which was how long ago? ;)
>>> Derek Atkins wrote:
>>>> Quoting Jason Wessel <jason.wessel at windriver.com>:
>>>>>> Um, okay..... How do I do that? My GDB Fu is weak here; how do I
>>>>>> tell gdb that the symbols in vmlinux are all offset? Or how do I
>>>>>> manipulate the vmlinux binary to offset the symbols?
>>>>> Start gdb with no file. And do something like: add-symbol-file vmlinux
>>>> Um, where did you get "0xBFA0000" from? Unfortunately this didn't
>>>> work at all. I would think to get my numbers to work I'd need to
>>>> use 0xC0400000 to get sys_close to appear at 0xc047d341. And
>>>> viola, that seems to work! Or at least I got a reasonable breakpoint
>>>> from the 'target remote'
>>> It was an example. You had previously stated it was an offset of
>>> 0x600000 so it was a subtraction of 0x600000 from 0xc0000000.
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> Kgdb-bugreport mailing list
>>> Kgdb-bugreport at lists.sourceforge.net
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the kexec