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 tested that one symbol.
I could go randomly sample some other symbols, too, if that would help.
It certainly seems weird to me, but it does seem consistent. :(
> If you knew for absolutely certain that everything was relocated with an
> offset, then you could simply load the symbols with an offset too. You
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?
> are not going to be able to "easily" debug kernel modules of course
> without patching gdb to have the kernel module support.
What patch do I need to support this? I thought that I just needed to
add-symbol-file <module> <offset>, right? Why wouldn't that work?
Thanks for the feedback!
> Jason.
-derek
> Derek Atkins wrote:
>> Hi everyone,
>>
>> I'm using Fedora 7; I've backported the 2.6.23-rc8-mm1 broken-out kgdb
>> patches (git-kgdb.patch, git-kgdb-fixup.patch,
>> kgdb-fix-docbook-and-kernel-doc-typos.patch, and
>> kgdb-fix-help-text.patch) to the Fedora 2.6.22.5-76 kernel
>> and I can connect just fine from my host system to the
>> target running in vmware.
>>
>> Unfortunately, gdb shows no symbols:
>>
>> [EMAIL PROTECTED] ~]$ gdb /vmlinux.kgdb
>> GNU gdb Red Hat Linux (6.6-15.fc7rh)
>> Copyright (C) 2006 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for details.
>> This GDB was configured as "i386-redhat-linux-gnu"...
>> Using host libthread_db library "/lib/libthread_db.so.1".
>> (gdb) target remote /dev/pts/18
>> Remote debugging using /dev/pts/18
>> warning: shared library handler failed to enable breakpoint
>> 0xc04579aa in ?? ()
>> (gdb) bt
>> #0 0xc04579aa in ?? ()
>> #1 0xc07a2fc8 in ?? ()
>> #2 0xc055fe3e in ?? ()
>> #3 0xc07a2fe0 in ?? ()
>> #4 0xc04597f6 in ?? ()
>> #5 0x00000004 in ?? ()
>> #6 0xc072a000 in ?? ()
>> #7 0x00000004 in ?? ()
>> #8 0xdfb247e0 in ?? ()
>> #9 0xc07a2ff8 in ?? ()
>> #10 0xc045ab73 in ?? ()
>> #11 0xc072a02c in ?? ()
>> #12 0xc0736f54 in ?? ()
>> #13 0x00000004 in ?? ()
>> #14 0xc045aaad in ?? ()
>> #15 0xc0736f70 in ?? ()
>> #16 0xc0407309 in ?? ()
>> #17 0x00000000 in ?? ()
>> (gdb) p sys_close
>> $1 = {long int (unsigned int)} 0xc107e341 <sys_close>
>> (gdb)
>>
>> This matches what's in the System.map file:
>>
>> [EMAIL PROTECTED] ~] grep sys_close .../System.map
>> c107e341 T sys_close
>> c12deb58 r __ksymtab_sys_close
>> c12e4918 r __kcrctab_sys_close
>> c12ea703 r __kstrtab_sys_close
>>
>> However, the system running this kernel shows a different value:
>>
>> [EMAIL PROTECTED] #] grep sys_close /proc/kallsyms
>> c047e341 T sys_close
>> c06deb58 r __ksymtab_sys_close
>> c06e4918 r __kcrctab_sys_close
>> c06ea703 r __kstrtab_sys_close
>>
>> I find it interesting that the symbols are EXACTLY 0x600000 different,
>> but I haven't been able to track down this difference. Am I doing
>> something wrong? Is there some particular kernel configuration I need
>> to set for my kernel? Why are the symbols in the running kernel at
>> different addresses than the underlying vmlinux?
>>
>> (I'll also note that I see a similar skew on my non-rebuilt Fedora
>> kernel, comparing System.map to /proc/kallsyms, so it's probably not
>> specifically a kgdb issue, it could be a Fedora issue.. but I'd still
>> like help in working around this disparity).
>>
>> Thanks in advance for any help.
>>
>> -derek
>>
>>
>
>
>
--
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
[EMAIL PROTECTED] PGP key available
-------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
