This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: How to portably print out Env of a Process
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: drow at false dot org
- Cc: gdb at sourceware dot org
- Date: Sun, 16 Jul 2006 16:08:12 +0200 (CEST)
- Subject: Re: How to portably print out Env of a Process
- References: <5f3d30900605222046t810dd4cue180cba7b0541fa7@mail.gmail.com> <200606171914.k5HJEJGY032428@elgar.sibelius.xs4all.nl> <20060712163910.GB22834@nevyn.them.org>
> Date: Wed, 12 Jul 2006 12:39:10 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> On Sat, Jun 17, 2006 at 09:14:19PM +0200, Mark Kettenis wrote:
> > Make sure you install libc with full debug info. It looks like you're
> > using Linux. Debian has packages with the necessary debug info.
> > Other distros might not. If your distro does not provide such
> > packages please complain.
>
> Actually, we (Debian) don't by default.
Well, you *do* give the user the opportunity to install those packages
and use them. Many other distros don't seem to do this.
The example was:
>
> p (char *) getenv("HOME")
>
> We ship two sets of debug libraries, both in the libc6-dbg package.
> One set are used automatically by GDB (via set debug-file-directory);
> these have only .debug_frame in them, and are used only for backtraces.
> The other includes symbolic debug info and is not used unless you
> specify LD_LIBRARY_PATH=/usr/lib/debug. They aren't the default
> because GDB takes a large amount of RAM and is much slower when given
> that much debug information, for an otherwise small program.
Hmm, yes, I'm noticing that on our (OpenBSD) slower platforms the
testsuite sometimes times out loading a program.
> I wonder if guessing "long" for return values might be more overall
> useful than guessing "int", for this exact reason? Is that likely to
> break anything not already broken?
I don't think that'd be a terribly good idea; the usage of "int" as
the default return value for unprototyped functions is pretty much
engrined in the C language.
Mark