Date:	Tue, 31 Jul 2001 12:12:06 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp-workers AT delorie DOT com, n_abing AT ns DOT roxas-online DOT net DOT ph
Subject:	Re: DJGPP core dumper
In-Reply-To:	<Pine.LNX.4.10.10107311047420.13133-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.1010731120815.1042R-100000@is>
MIME-Version:	1.0
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

On Tue, 31 Jul 2001, Hans-Bernhard Broeker wrote:

> On Sat, 28 Jul 2001, Eli Zaretskii wrote:
> 
> > Finally, I'm not sure what to do with the environment and backtrace
> > sections: GDB doesn't use them.  
> 
> But maybe the special coredump-interpreting program that came with that
> package does?

Maybe.  But this info is redundant: the memory dump already has it.

Also, I don't understand why is it so important to have environ[] stashed 
away separately.  How is it different from any other global variable used 
internally by the library?

> The struct field is written to by
> 
> 	elfcore_grok_psinfo (bfd/elf.c)
> 
> by copying it out of the 'ps info' structure. In short: yes, this is
> argv[], if available.
> 
> [Cscope is really a nice tool for digging up stuff like this...]

Well, I've seen all this even without CScope, except that I was looking 
inside GDB and so didn't see binutils/size.c; thanks.

FWIW, it looks like GDB itself never uses the info in this field; Cygwin 
doesn't even compute it, probably for that same reason.

- Raw text -