Re: How to portably print out Env of a Process

[Daniel Jacobowitz <drow@false.org>]

On Sun, Jul 16, 2006 at 04:08:12PM +0200, Mark Kettenis wrote:
> > 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.

Yes, I used to have to strip target libraries on several platforms to
test GDB.

> > 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.

Sure.  But does that matter in this context?

Suppose int and long are the same size.  Then there's no difference.

Suppose they're different sizes and the function returns int.  On all
GDB-supported platforms that I can think of, where long is a different
size from int, the return conventions are such that this doesn't make a
difference.  We'll display the right result.

Suppose they're different sizes and the function returns long or a
pointer.  The change would help.

I think it's a good idea; but can you give me an example where it
wouldn't be?

-- 
Daniel Jacobowitz
CodeSourcery