Date:	Fri, 17 Nov 2000 10:28:58 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Message-Id:	<3405-Fri17Nov2000102857+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<5.0.1.4.0.20001116230739.00a55af0@pop5.banet.net>
	(pjfarley AT banet DOT net)
Subject:	Re: Help: Isn't libdbg the debugging version of libc?
References:	<5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001116230739 DOT 00a55af0 AT pop5 DOT banet DOT net>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> Date: Thu, 16 Nov 2000 23:21:57 -0500
> From: "Peter J. Farley III" <pjfarley AT banet DOT net>
> 
> OK, I'm trying to debug Mark E.'s enhanced fcntl, but gdb won't step 
> into any libc function.

I assume you mean ``step'' as in "(gdb) step", not as in "(gdb} stepi",
because stepping on the assembly level should work with libc functions.

> Can you point me at any info or docs on the right way to make and use a 
> debugging version of libc for gdb testing of fcntl?

There is no debugging version of libc.a, right now.  It might be a
good idea to supply such a version (and also another version, compiled
with -pg), but no one bothered to make that happen yet.

Btw, I think our specs file doesn't support these special versions,
either.  Normally, it should instruct GCC to link against libc_g.a
when given the -g switch, and against libc_p.a when given the -pg
switch; I don't see the necessary magic in our specs, probably because
these libraries were never available.  If we ever produce these
libraries, specs will need to be changed.  (Perhaps it's a good idea
to make this change in the next GCC release, just in case.)

What I usually do when I need to debug library functions is to paste
their source into my test program, compile and link with -g and debug
at will.  When I'm done debugging, I put the modified version into
libc.a.  This is easier than producing a debugging version of the
library and futzing with link command line (to force the linker to use
the debugging version, since specs doesn't do that).

> BTW, the current "tests\makefile.inc" expects libgcc.a to be in the 
> "${LIB}" directory, but it is now in "${LIB}/gcc-lib/djgpp/2.952".

This is because djdev203 was built with GCC 2.8.1, not 2.95.2.  I
expect quite a few of such minor nuisances to pop up when migrating to
GCC 2.9x or 3.x.  The ones that truly scare me are the more strict
warnings.

> I had to update "tests\makefile.inc" to change that assumption.

Please post the diffs, we should change the CVS repository
accordingly.

It would be nice if a way could be found to work with both old and new
GCC versions.  Please see if you can make a change that works either
way.  I think the library build procedure does something like that.

- Raw text -