On 06/12/09 11:48, Steve Gonczi wrote:
> By all means, please share your hacks.
>
> I am not sure why switching to dwarf would make any difference, given that
> stabs is the native Sun format, dbx can surely handle it.
From what I've learned, the bug isn't in dbx. Yes, it can read stabs.
But somehow the compilation process isn't generating them correctly.
> I could see the point if you are using a recent gdb maybe.
>
> For me, the ctf* utilities are the likely problem, but seems I can not
> disable running these because then some of the dynamically generated header
> files do not get built.
>
First, I did a full build of the entire workspace.
Now cd to the <workspace>/usr/src/lib/libzfs directory (You will need to
go the libzpool directory).
% make clobber
% make install > doit 2>&1
Now edit the file "doit" to
a) remove all lines beginning with "+"
b) modify the lines that simply name a directory to prefix them with
"cd". i.e.,
this line:
/builds/lalt/onnv/usr/src/lib/libzfs/i386
becomes:
cd /builds/lalt/onnv/usr/src/lib/libzfs/i386
c) globally replace the string:
-xdebugformat=stabs
with
-xdebugformat=dwarf
Now, while your current directory is <repo>/usr/src/lib/libzfs, execute
"doit" as a script.
At this point, I can now run a problem under dbx which accesses
libzfs.so.1 (you
might have to set LD_LIBRARY_PATH) to make sure you're using the one
you just built, not whatever is in /lib) and debug functions in the
libzfs.so.1 library.
That is, I no longer get messages like:
(dbx) stop in zfs_send
dbx: warning: 'zfs_send' has no debugger info -- will trigger on first
instruction
I think you may be right that it's the ctf* functions (which run silently
during post processing) that are run by "make" that end up removing the
debugger info. Doing the compiles and links explicitly with a script
like this suppresses that step. Yes, I'm sure that there are cleaner
ways to
get around this, but I'm tired of experimenting and this works for me.
Lori
