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. -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 >
