Debugging the ZDB debugger.
K. Macy
kmacy at freebsd.org
Fri Nov 21 06:32:47 UTC 2014
Clang is very good at minimizing the live range of variables. As of
that point in the function dl is no longer needed (by zdb), so if it
is still available it will be in a non-callee save register. Whether
or not it's still valid is more or less up to chance. You can often
infer the value from disassembling and looking at the registers.
However, you're not looking at some user's kernel core dump that you
can't ask him to reproduce. You can ensure that every variable used,
regardless of its liveness, is allocated a location on the stack by
compiling with -O0. I believe -O2 is actually set somewhere in the .mk
files, so naively you need to set CFLAGS=-O0 and add in explicitly
whatever flags it's passed that it needs. I'd be surprised if there
isn't a much cleaner way to do it but I'm not familiar with build
magic.
-K
On Thu, Nov 20, 2014 at 10:25 PM, Zaphod Beeblebrox <zbeeble at gmail.com> wrote:
> Ok... that advice got me somewhere... now my stack is:
>
> (gdb) bt
> #0 0x00000000004098a9 in dump_dir (os=0x80d302000)
> at
> /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:1464
> #1 0x0000000000406222 in main (argc=0, argv=<value optimized out>)
> at
> /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:3604
>
> and we got here on a segmentation fault. Now ... I'm a little confused:
>
> (gdb) frame 0
> #0 0x00000000004098a9 in dump_dir (os=0x80d302000)
> at
> /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:1464
> 1464 zdb_nicenum(dl->dl_phys->dl_used, bytes);
> (gdb) p dl
> No symbol "dl" in current context.
> (gdb) p *dl
> No symbol "dl" in current context.
>
> I thought for a second that I was using gdb wrong (it's been awhile), but:
>
> (gdb) frame 1
> #1 0x0000000000406222 in main (argc=0, argv=<value optimized out>)
> at
> /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:3604
> 3604 dump_dir(os);
> (gdb) p os
> $3 = (objset_t *) 0x80d302000
>
> ... my first thought was "is the stack trashed"? ... but shouldn't gdb know
> what 'dl' is regardless of the process state?
>
> Then I realized that line 1464 isn't in dump_dir() ... it's in dump_dead()
>
> help?
More information about the freebsd-hackers
mailing list