At Sun, 07 Mar 2010 19:00:36 -0500, Richard Hansen <rhansen%bbn.com@localhost>
wrote:
Subject: Re: Confused about MKBUILD=yes
>
> > You need all of the following:
> >
> > MKDEBUG= yes
>
> Unfortunately, this only affects programs, not libraries.
That's why I said you need _all_ of the settings I suggested, together,
but read on as I was over-doing it a wee bit....
> > MKDEBUGLIB= yes
>
> This only adds -DDEBUG to the preprocessor flags (for libraries only,
> not programs). I don't want to change the behavior of the libraries; I
> just want debug symbols so that gdb gives me useful backtraces.
Have a look in share/mk/bsd.lib.mk. MKDEBUGLIB builds lib*_g.a
libraries (with -DDEBUG, as you've seen).
Hmmm... I guess this doesn't matter with static linking though, since
lib*.a will also still contain the debugging symbols. I guess the only
difference with the lib*_g.a libraries is they've also been compiled
with -DDEBUG turned on too.
I guess you can ignore MKDEBUGLIB.
DBG=-g is the real secret sauce -- and MKDEBUG is just the way that
/usr/libdata/debug gets populated.
> > DBG= -g
>
> Isn't the DBG variable an implementation detail? I don't see it
> documented anywhere.
The value of DBG is included in CFLAGS.
See share/mk/sys.mk.
A lot of what's in sys.mk is not documented.
My local changes to share/mk/bsd.README may help clarify why MKDEBUG
alone is not sufficient:
-MKDEBUG If "no", don't build and install separate debugging
symbols
- into /usr/libdata/debug.
+MKDEBUG If "no", don't build and install separate debugging
+ symbols into /usr/libdata/debug. To be useful "DBG=-g"
+ must also be set. STRIPFLAG can be set to "-s".
Default: no
So, MKDEBUG only controls creation of files for /usr/libdata/debug.
> Also, DBG seems to only be used for optimization,
> not debug.
That's because it has been rather lamely overloaded, presumably due to
ancient folklore that "-g" and "-O" don't mix (but they do with gcc, at
least to -O2, for some definition of reasonably).
That's also why I said I separated them out and added my own OPTIM
variable in parallel to DBG.
Actually now that I look again I see the following in my mk.conf that I
had forgotten all about:
# in NetBSD-3 and newer they've finally come up with an equivalent to my
# ${OPTIM}, but it's called CPUFLAGS...
#
CPUFLAGS ?= $(OPTIM)
But that's not quite right either, since by default it's used to turn on
warnings, not control anything about code generation. I should check to
see if what I'm doing there isn't doubling up the "-O2" in my commands.
> COPTS is documented and intended to be used in mk.conf, so my first
> instinct is to use it instead. But really I'd rather just set
> MKDEBUG=yes and have everything work as expected.
I think COPTS is for other things, like -mcpu, -pipe, -mtune, etc.
There are way too many ways to pass flags to the compiler. :-)
> > The "debug" symbols are stripped and saved to a hierarchy of files in
> > /usr/libdata/debug.
>
> I don't think the debug symbols are stripped -- they're just *copied* to
> /usr/libdata/debug. Here are the relevant lines from bsd.prog.mk:
Indeed -- they're not stripped unless you also set STRIPFLAG=-s
In netbsd-1.6.x I used STRIPFLAG="-sS -g", but I've found that with
/usr/libdata/debug I don't really need to leave any symbols in the
executable files any more.
> > You can load these *.debug symbol files in gdb with
> > the "symbol-file" command.
>
> I don't think the symbol-file command is needed; gdb will see the
> .gnu_debuglink section in the ELF binary and simply load the file listed
> there.
Well, it is needed if your binaries have been stripped of symbols. :-)
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpCv5Wg3i2oh.pgp
Description: PGP signature