[Kgdb-bugreport] Problem getting kgdb to read kernel symbols. addresses shifted?

[Eric W. Biederman]

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.

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.

I'm running on foggy memories so something may have changed
since last time I looked.

Eric


>
> -piet
>
>> 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
>>>> 0xBFA00000
>>> 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.
>> 
>> Jaosn.
>> 
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Kgdb-bugreport mailing list
>> Kgdb-bugreport at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
>>