From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28637 invoked by alias); 17 Jul 2006 00:37:47 -0000 Received: (qmail 28628 invoked by uid 22791); 17 Jul 2006 00:37:46 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 17 Jul 2006 00:37:44 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G2H7G-0007U5-Tr; Sun, 16 Jul 2006 20:37:43 -0400 Date: Mon, 17 Jul 2006 00:57:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org Subject: Re: How to portably print out Env of a Process Message-ID: <20060717003742.GA28416@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org References: <5f3d30900605222046t810dd4cue180cba7b0541fa7@mail.gmail.com> <200606171914.k5HJEJGY032428@elgar.sibelius.xs4all.nl> <20060712163910.GB22834@nevyn.them.org> <200607161408.k6GE8ChA009499@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607161408.k6GE8ChA009499@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00108.txt.bz2 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