I hadn't actually noticed as I'd never tried to use the ::getenv dcmd before but, by default, it doesn't operate on the target process. This kind of surprised me.
I understand the need to be able to prepare an environment for a process that I'm going to ::run but I'd have expected that the default when I'm attached to a process or debugging a core would be the target I'm currently debugging. Maybe it's just me. The ::getenv and ::setenv dcmd didn't seem to make it into the mdb guide for Solaris 10 so I'll log a doc bug. I'll also log an rfe for a more descriptive help message on ::getenv. Cheers. Jon. Michael Shapiro wrote: >>--- Jonathan Haslam <Jonathan.Haslam at Sun.COM> wrote: >> >> >>>Hi Stefan, >>> >>>The ::getenv dcmd was only introduced in Solaris 10. >> >>right, thanks. That explains. >> >>I will try tomorrow to see if I'm able to extract the >>information using " the pr_envp pointer >>in the psinfo_t struct" >> >>I'm trying to figure out how. >> >>thanks, >>Stefan > > > pr_envp is the *original* environ pointer created by exec(). But if the > application has undergone a large number of setenv()s, then the array > may have needed to be resized, in which case that value isn't the > proper one anymore. (Technically a process could also reassign _environ > directly, although that isn't kosher from a POSIX perspective) So you > really need to lookup _environ and read the array it refers to. > > My recommendation would be to either take the code for mdb's ::getenv > or pargs (usr/src/cmd/ptools/pargs/pargs.c), now conveniently OpenSourced > for your viewing pleasure, and recompile it on your Solaris 8 system. > Pargs may require some newer stuff from libproc, but you can take that too. > Alternately, it should be pretty easy to take the S10 mdb ::getenv > and recompile that as a stand-alone mdb module for S8. > > -Mike >
