I have not looked at the fedora kernels, but it would appear that if
there was a shift that some part of the loader or some kernel patch has
done a runtime relocation.
If you knew for absolutely certain that everything was relocated with an
offset, then you could simply load the symbols with an
Derek Atkins wrote:
Hi,
Jason Wessel [EMAIL PROTECTED] writes:
I have not looked at the fedora kernels, but it would appear that if
there was a shift that some part of the loader or some kernel patch has
done a runtime relocation.
Well, it appears to be the case, but I've only
Quoting Jason Wessel [EMAIL PROTECTED]:
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
Derek Atkins wrote:
Quoting Jason Wessel [EMAIL PROTECTED]:
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
Pete/Piet Delaney [EMAIL PROTECTED] 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
Derek Atkins [EMAIL PROTECTED] writes:
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.
Ok. So we must have a relocatable
