Determinig the environment of a process

[Ralph Grothe]

Hi Dietmar,

your hint towards attaching to a running proc with a debugger sounds very promissing to me.
However not being a C hacker I lack mastery of the adb (I take I can use it for this purpose), and hence a liitle more help.
From adb's manpage I see that I could use -P switch to attach to a PID.
If I recall my embryonic C knowledge the main function gets as first two args the arc (argument count) and an **argv (argument array), and optionally an **env (environment array).
The latter I think can be fetched by the syscall getenv().
So it would be great if there was some sort of debugger getenv() call.
On the other hand I thought in order to fetch symbols from an object file (or proc/executable) that binary must have been compiled with an option that reserves memomry for the symbols as well, and that this would almost never be done on a final program release past the debugging stage because of waste of memory, right?
So will there be a chance at all to fetch environment variables from a non-debug-built binary?
But even if the binary provided symbol tables how would I have to invoke, say the adb debugger, to get the contents of environment variables displayed (i.e. which adb commands, typing, formatting etc.)?

[Ralph Grothe]

Em, forgot,
what the hack is my local HP Response Centre?
I can't believe it's the Berlin HP subsidiary.
Thought all vital design and coding decissions were made in Hanover Street anyway?

[Steven E. Protter]

Maybe its not local, but if you have a software contract you can call A HP Response center or do an online case on this issue.

I don't know how that would be done in Berlin.

I am very interested in this issue because being able to determine the environment of a process after or while its running.

SEP

[Ralph Grothe]

Hi Steven,

we do have support contracts to issue HP support cases over a countrywide hotline.
Probably I should ask them, or browse a bit through ITRC.

To pick up the thread,
Dietmar has mailed me a hack meanwile that seems to apply to gdb.
Unfortunately I have installed gdb on only one (other) HP-UX box.
But I will try there.
This hack looks to me a bit of a mixture between shell scripting and C (viz. thingies that look like C type casts to me).
It seems to be a sort of gsb scripting dialect.
I'm sure it would make more sense to you,
although it's easy to gather.
Maybe Dietmar was so kind to also post this hack here for the community.
(then I could also thank him with some points ;-)

[Dietmar Konermann]

Ralph,

your "local HP Response Center" is the German one, located in Ratingen.

For enhancements you should go the official way (which is logging a call with the repsonse center for that) since the request should also contain information about business impact/opportunities and your support level to get the desired drive. ;-)

For the technical background... an exec'ed process gets its enviroment as "an null-terminated array of character pointers to null-terminated strings" (man exec(2)).

For 32bit processes this gdb script usually works (no guarantee!):

# env32.gdb
set $start=*0x40001000
set $i=$start+4
printf "\nCommand Line:\n"
while *$i != $start
set $i=$i+4
end
while *$i != 0
x/s *$i
set $i=$i+4
end
set $i=$i+4
printf "\nEnvironment:\n"
while *$i != 0
x/s *$i
set $i=$i+4
end
q


For 64bit processes try this script instead:

# env64.gdb
printf "\nCommand Line:\n"
set $i=0
while ((char **)__argv)[$i] != 0
print ((char **)__argv)[$i]
set $i=$i+1
end
printf "\nEnvironment:\n"
set $i=0
while ((char **)__envp)[$i] != 0
print ((char **)__envp)[$i]
set $i=$i+1
end
q

To call gdb with a script file, e.g. env32.gdb:

# gdb -x env32.gdb

No guarantee for all that stuff.

Best regards...
Dietmar.