How to portably print out Env of a Process

How to portably print out Env of a Process

[Arijit Das]

Hi,

Is it possible to print out the env of a process portably with the
same cmdline/script in different os/arch combinations?

Here is how I tried to do it for i686 - RH3.0:

(gdb) p (char *) getenv("HOME")
[Switching to Thread 1024 (LWP 17639)]
$1 = 0xdffff781 "/remote/vtghome7/arijit"
(gdb)

It worked fine.

But when I tried executing this command in x86_64, I got strange results:

(gdb) p (char *) getenv("HOME")
[Switching to Thread 182901576896 (LWP 26427)]
$1 = 0xffffffffbfffc790 <Address 0xffffffffbfffc790 out of bounds>
(gdb)

I guess some kind of 32/64 bits conversion might be messing things up
here....but am not sure exactly what? Any help here?

Thanks,
Arijit

Re: How to portably print out Env of a Process

[Bob Rossi]

On Tue, May 23, 2006 at 09:16:42AM +0530, Arijit Das wrote:
> Hi,
> 
> Is it possible to print out the env of a process portably with the
> same cmdline/script in different os/arch combinations?
> 
> Here is how I tried to do it for i686 - RH3.0:
> 
> (gdb) p (char *) getenv("HOME")
> [Switching to Thread 1024 (LWP 17639)]
> $1 = 0xdffff781 "/remote/vtghome7/arijit"
> (gdb)
> 
> It worked fine.
> 
> But when I tried executing this command in x86_64, I got strange results:
> 
> (gdb) p (char *) getenv("HOME")
> [Switching to Thread 182901576896 (LWP 26427)]
> $1 = 0xffffffffbfffc790 <Address 0xffffffffbfffc790 out of bounds>
> (gdb)
> 
> I guess some kind of 32/64 bits conversion might be messing things up
> here....but am not sure exactly what? Any help here?

How about, 'shell echo $HOME'?

Bob Rossi

Re: How to portably print out Env of a Process

[Daniel Jacobowitz]

On Tue, May 23, 2006 at 08:56:22AM -0400, Bob Rossi wrote:
> On Tue, May 23, 2006 at 09:16:42AM +0530, Arijit Das wrote:
> > Hi,
> > 
> > Is it possible to print out the env of a process portably with the
> > same cmdline/script in different os/arch combinations?
> > 
> > Here is how I tried to do it for i686 - RH3.0:
> > 
> > (gdb) p (char *) getenv("HOME")
> > [Switching to Thread 1024 (LWP 17639)]
> > $1 = 0xdffff781 "/remote/vtghome7/arijit"
> > (gdb)
> > 
> > It worked fine.
> > 
> > But when I tried executing this command in x86_64, I got strange results:
> > 
> > (gdb) p (char *) getenv("HOME")
> > [Switching to Thread 182901576896 (LWP 26427)]
> > $1 = 0xffffffffbfffc790 <Address 0xffffffffbfffc790 out of bounds>
> > (gdb)
> > 
> > I guess some kind of 32/64 bits conversion might be messing things up
> > here....but am not sure exactly what? Any help here?

Exactly.  Try this:

(gdb) p ((char * (*)()) getenv) ("HOME")

I first tried (char * (*) (char *)), but GDB reported that as an
invalid cast.  I'm not sure why.

> 
> How about, 'shell echo $HOME'?

If you wanted that, "show env", but you don't - the child's might be
different.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to portably print out Env of a Process

[Arijit Das]

Thanks...

(gdb) p ((char * (*)()) getenv) ("HOME")

seems to be working fine so far. But couldn't make sense of the cast
logically. As you said, ideally, it should have been something like

(gdb) p ((char * (*)(const char *)) getenv) ("HOME")

which doesn't work!

-Arijit

On 5/23/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, May 23, 2006 at 08:56:22AM -0400, Bob Rossi wrote:
> > On Tue, May 23, 2006 at 09:16:42AM +0530, Arijit Das wrote:
> > > Hi,
> > >
> > > Is it possible to print out the env of a process portably with the
> > > same cmdline/script in different os/arch combinations?
> > >
> > > Here is how I tried to do it for i686 - RH3.0:
> > >
> > > (gdb) p (char *) getenv("HOME")
> > > [Switching to Thread 1024 (LWP 17639)]
> > > $1 = 0xdffff781 "/remote/vtghome7/arijit"
> > > (gdb)
> > >
> > > It worked fine.
> > >
> > > But when I tried executing this command in x86_64, I got strange results:
> > >
> > > (gdb) p (char *) getenv("HOME")
> > > [Switching to Thread 182901576896 (LWP 26427)]
> > > $1 = 0xffffffffbfffc790 <Address 0xffffffffbfffc790 out of bounds>
> > > (gdb)
> > >
> > > I guess some kind of 32/64 bits conversion might be messing things up
> > > here....but am not sure exactly what? Any help here?
>
> Exactly.  Try this:
>
> (gdb) p ((char * (*)()) getenv) ("HOME")
>
> I first tried (char * (*) (char *)), but GDB reported that as an
> invalid cast.  I'm not sure why.
>
> >
> > How about, 'shell echo $HOME'?
>
> If you wanted that, "show env", but you don't - the child's might be
> different.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: How to portably print out Env of a Process

[Mark Kettenis]

> X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on 
> 	elgar.sibelius.xs4all.nl
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
> 	version=3.1.1
> Date: Tue, 23 May 2006 09:16:42 +0530
> From: "Arijit Das" <arijit79@gmail.com>
> Content-Disposition: inline
> X-IsSubscribed: yes
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.org
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-UTwente-MailScanner-SpamScore: s
> X-UTwente-MailScanner-From: gdb-return-25381-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> X-XS4ALL-DNSBL-Checked: mxdrop44.xs4all.nl checked 130.89.2.8 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0.401 () FROM_ENDS_IN_NUMS,HTML_MESSAGE
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> X-MIME-Autoconverted: from quoted-printable to 8bit by mxdrop44.xs4all.nl id k4N3lNcQ019572
> X-UIDL: 1148356045._smtp.mxdrop44.19580,S=3409
> 
> Hi,
> 
> Is it possible to print out the env of a process portably with the
> same cmdline/script in different os/arch combinations?
> 
> Here is how I tried to do it for i686 - RH3.0:
> 
> (gdb) p (char *) getenv("HOME")
> [Switching to Thread 1024 (LWP 17639)]
> $1 = 0xdffff781 "/remote/vtghome7/arijit"
> (gdb)
> 
> It worked fine.
> 
> But when I tried executing this command in x86_64, I got strange results:
> 
> (gdb) p (char *) getenv("HOME")
> [Switching to Thread 182901576896 (LWP 26427)]
> $1 = 0xffffffffbfffc790 <Address 0xffffffffbfffc790 out of bounds>
> (gdb)
> 
> I guess some kind of 32/64 bits conversion might be messing things up
> here....but am not sure exactly what? Any help here?
> 

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.

Cheers,

Mark

Re: How to portably print out Env of a Process

[Daniel Jacobowitz]

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

So, if you are running a program that includes the header defining
getenv, and your program is compiled with -g, the example will work.
And if you use the libc6-dbg libraries explicitly, the example will
work.  Otherwise, GDB has to guess, and guesses wrong.

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?

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to portably print out Env of a Process

[Daniel Jacobowitz]

On Wed, May 24, 2006 at 10:13:16AM +0530, Arijit Das wrote:
> Thanks...
> 
> (gdb) p ((char * (*)()) getenv) ("HOME")
> 
> seems to be working fine so far. But couldn't make sense of the cast
> logically. As you said, ideally, it should have been something like
> 
> (gdb) p ((char * (*)(const char *)) getenv) ("HOME")
> 
> which doesn't work!

I haven't got the time it's going to take to fix this right now, but I
do see what's wrong.  It's a combination of two things.  One is
the "const"; push_type and follow_types don't have any scoping in them,
so a call to follow_types always eats everything on the stack.  Which
eats the bit making this a pointer to a function instead of a function.

The other is that the func_mod rule in c-exp.y just discards the
arguments.  We never look at them.

This is all somewhat lame, but will be tricky to improve without
breaking something that already works.

Thanks for reporting this!

-- 
Daniel Jacobowitz
CodeSourcery

Re: How to portably print out Env of a Process

[Mark Kettenis]

> 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

Re: How to portably print out Env of a Process

[Daniel Jacobowitz]

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