Date: Wed, 14 Oct 1998 13:59:55 +0800 From: Peter Wemm <peter@netplex.com.au> To: Greg Lehey <grog@lemis.com> Cc: Karl Pielorz <kpielorz@tdx.co.uk>, Edwin Culp <eculp@webwizard.org.mx>, FreeBSD-current@FreeBSD.ORG Subject: Re: Make elf release Message-ID: <199810140559.NAA04261@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 14 Oct 1998 11:22:20 %2B0930." <19981014112220.A21983@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:
> [Format autorecovered at freebie.lemis.com]
>
> On Wednesday, 14 October 1998 at 7:59:23 +0800, Peter Wemm wrote:
> > Karl Pielorz wrote:
> >> Edwin Culp wrote:
> >>>> I know that's one of the reasons why I've left my system running a.out k
ernels
> >>>> at the moment... (and I at least hope it's a good reason ;-)
> >>>
> >>> The wonderful part of it is that I haven't had anything to debug :-) Wha
t of
> >>> the folks running current/beta debug their kernels? The way to find the
p roblems
> >>> is to have more people using it in its most complete form. IMO.
> >>
> >> Hmmm.. Well if I'm right about not being able to debug LDK's with an ELF
> >> kernel, I have to keep my kernel a.out... An LKM I'm betaing has a few
> >> problems, which means it's gotta be debug(able)...
> >
> > Umm, it's the other way around.. DDB can't see a.out LKM's for debugging.
> > DDB *can* see both a.out and elf KLD modules. KLD modules are the first
> > time that DDB has worked with modular kernels.
>
> Does this mean that there's the potential to have symbol conflicts?
Only if you have multiple symbols with the same name.. DDB can't be
reasonably be expected to figure out which "static int debug" you mean if
you've got several of them loaded in seperate modules.
In a backtrace from DDB though, it has no problem with multiple symbols of
the same name because it's keyed from the address.
> > It's GDB that is the problem - it can't see KLD modules. Mind you, it
> > can't see LKM's either.
>
> That's not correct. Here's a backtrace through the Vinum LKM:
>
> (kgdb) bt
> #0 Debugger (msg=0xf5b8cfe0 "vinum debug") at ../../i386/i386/db_interface.c
:317
> #1 0xf5b8d2d6 in vinumioctl (dev=0x40001900, cmd=0xc008464b, data=0xf5b4aed0
"", flag=0x3, p=0xf5a2bbc0)
> at vinumioctl.c:107
> #2 0xf016f44b in spec_ioctl (ap=0xf5b4ae0c) at ../../miscfs/specfs/spec_vnop
s.c:425
> #3 0xf016ed29 in spec_vnoperate (ap=0xf5b4ae0c) at ../../miscfs/specfs/spec_
vnops.c:129
> #4 0xf01da0d9 in ufs_vnoperatespec (ap=0xf5b4ae0c) at ../../ufs/ufs/ufs_vnop
s.c:2303
OK, but don't forget that the /usr/bin/gdb in 3.0 release is the elf
version.. It doesn't understand a.out (ether user binaries or kernels/
lkm's):
/tmp-102> gdb /kernel.aout
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
"/kernel": not in executable format: File format not recognized
(kgdb)
/tmp-103> file /kernel
/kernel: unknown pure executable
On the other hand, your trick works just fine with ELF as well, with one
variation:
pwroot@overcee[2:17pm]~peter/sys_elf/alpha/alpha-140# gdb -k /kernel /dev/mem
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)...
IdlePTD 2641920
initial pcb at 13aa000
panic messages:
---
---
#0 0xf013ce65 in mi_switch ()
(kgdb) add-symbol-file /modules/testmod.ko 0xf02782a0
add symbol table from file "/modules/testmod.ko" at text_addr = 0xf02782a0?
(y or n) y
(no debugging symbols found)...
(kgdb) disassemble test_function
Dump of assembler code for function test_function:
0xf02782a0 <test_function>: pushl %ebp
0xf02782a1 <test_function+1>: movl %esp,%ebp
0xf02782a3 <test_function+3>: pushl $0xf02782fc
0xf02782a8 <test_function+8>: call 0xf01419bc <printf>
0xf02782ad <test_function+13>: leave
0xf02782ae <test_function+14>: ret
0xf02782af <test_function+15>: nop
End of assembler dump.
pwroot@overcee[2:18pm]~peter/sys_elf/alpha/alpha-141# objdump --all-headers /modules/testmod.ko | more
/modules/testmod.ko: file format elf32-i386
/modules/testmod.ko
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000002a0
^^^^^^^^^^
[..]
The gotcha was that under ELF there is a variable amount of header
information. It shouldn't be too much trouble to teach GDB about this (as
with LKM's).
DDB does not see LKM's though. Also, DDB still has enough access to
symbols even on a strip(1)ed kernel and modules.
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
"No coffee, No workee!" :-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810140559.NAA04261>