I recently discovered the "pargs" command in Solaris 9.
What is the "alternate vector"?

Observe:
% pargs -x 931
931:    tcsh
AT_SUN_PLATFORM 0xffbfffd3 SUNW,UltraAX-i2
AT_SUN_EXECNAME 0xffbfffe3 /bin/tcsh
AT_PHDR         0x00010034
AT_PHENT        0x00000020
AT_PHNUM        0x00000005
AT_ENTRY        0x0001a5b0
AT_SUN_LDDATA   0xff3f6000
AT_BASE         0xff3c0000
AT_FLAGS        0x00000300
AT_PAGESZ       0x00002000
AT_SUN_UID      0x00000cf2 1234(user)
AT_SUN_RUID     0x00000cf2 1234(user)
AT_SUN_GID      0x00000064 123(group)
AT_SUN_RGID     0x00000064 123(group)
AT_SUN_HWCAP    0x00000007 HWMUL_32x32 | HWDIV_32x32 | HWFSMULD

[ Post a follow-up to this message ]

gazelle@yin.interaccess.com (Kenny McCormack) writes:

> I recently discovered the "pargs" command in Solaris 9.
> What is the "alternate vector"?

It's not "alternate vector", but an "auxiliary vector".

It is an array of values that the kernel passes on to the dynamic
loader (ld.so), in order to make loader's life easier.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

In article <m3d607424a.fsf@salmon.parasoft.com>,
Paul Pluzhnikov  <ppluzhnikov-nsp@charter.net> wrote:
>gazelle@yin.interaccess.com (Kenny McCormack) writes:
> 
>
>It's not "alternate vector", but an "auxiliary vector".

Noted.

>It is an array of values that the kernel passes on to the dynamic
>loader (ld.so), in order to make loader's life easier.

OK - so far so good.  Care to say more?
Are these environment variables of some sort?

[ Post a follow-up to this message ]

In article <cjjtqc$dji$1@yin.interaccess.com>,
gazelle@yin.interaccess.com (Kenny McCormack) wrote:

> In article <m3d607424a.fsf@salmon.parasoft.com>,
> Paul Pluzhnikov  <ppluzhnikov-nsp@charter.net> wrote: 
>
> Noted.
> 
>
> OK - so far so good.  Care to say more?
> Are these environment variables of some sort?

No, they're more like things the dynamic linker needs to know in order to
operate -- the full path to the executable, the platform name, the
location of the program header for the executable invoked, the location
of the start symbol for the executable, the location of the dynamic
linker itself, and flags for hardware capabilities the system supports.

For example, for a ksh shell on my sparcv9 Sun Blade 2500, the auxv
looks like:

$ pargs -x $$
195135: ksh
AT_SUN_PLATFORM 0xffbfffd8 SUNW,Sun-Blade-2500
AT_SUN_EXECNAME 0xffbfffec /usr/bin/ksh
AT_PHDR         0x00010034
AT_PHENT        0x00000020
AT_PHNUM        0x00000006
AT_ENTRY        0x00016944
AT_SUN_LDDATA   0xff3ec000
AT_BASE         0xff3b0000
AT_FLAGS        0x00000b00
AT_PAGESZ       0x00002000
AT_SUN_AUXFLAGS 0x00000002
AT_SUN_HWCAP    0x0000006b VIS2 | VIS | V8PLUS | DIV32 | MUL32

and the address space of the process looks like:
$ pmap $$
195135: ksh
00010000     200K r-x--  /usr/bin/ksh
00052000       8K rwx--  /usr/bin/ksh
00054000      40K rwx--    [ heap ]
FF276000       8K rwxs-    [ anon ]
FF280000     864K r-x--  /lib/libc.so.1
FF368000      32K rwx--  /lib/libc.so.1
FF370000       8K rwx--  /lib/libc.so.1
FF380000       8K r-x--  /platform/sun4u-us3/lib/libc_psr.so.1
FF390000      64K rwx--    [ anon ]
FF3B0000     176K r-x--  /lib/ld.so.1
FF3EC000       8K rwx--  /lib/ld.so.1
FF3EE000       8K rwx--  /lib/ld.so.1
FFBFC000      16K rw---    [ stack ]
total      1440K

Notice that the "AT_PHDR" (program header) points near the beginning of
the text segment of the KSH binary (right after the main ELF header,
actually), AT_BASE points at the base of the dynamic linker (ld.so.1)
and AT_SUN_LDDATA points to the beginning of the dynamic linker's data
segment.

You can look at /usr/include/sys/auxv.h for the definitions of (and a
small amount of descriptive text about) the AT_* flags.

- jonathan

[ Post a follow-up to this message ]

Jonathan Adams <jwadams@gmail.com> writes:

> No, they're more like things the dynamic linker needs to know in order to
> operate -- the full path to the executable, the platform name, the
> location of the program header for the executable invoked, the location
> of the start symbol for the executable, the location of the dynamic
> linker itself, and flags for hardware capabilities the system supports.

It's not as if dynamic linker couldn't find most of these by itself.

However, since the kernel already knows all of this, it can simply
pass on the info, saving the loader some (minimal) work.

An added bonus is that the loader doesn't have to have its own copy
of a few of libc functions (for obvious reasons the loader can't
use libc.so). I don't know whether that was the real motivation for
the AT_ vector.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:

>It's not as if dynamic linker couldn't find most of these by itself.

There's a buit of information the dynamic linker cannot
derive but which the kernel does know.

(AT_SUNW_EXECNAME, AT_SUNW_AUXFLAGS)

It's also about performance; to derive all information
you need to perform around 10-20 system calls.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

In article <415e7b8f$0$78749$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> writes:
> Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
> 
>
> There's a buit of information the dynamic linker cannot
> derive but which the kernel does know.
>
> (AT_SUNW_EXECNAME, AT_SUNW_AUXFLAGS)
>
> It's also about performance; to derive all information
> you need to perform around 10-20 system calls.
>

Is AT_SUNW_AUXFLAGS a Solaris 10 thing?  I can't find it in
any of the sys/aux*.h on Solaris 9 (nor anywhere in the
/usr/platform/*/include trees).

--
mailto:rlhamil@smart.net  http://www.smart.net/~rlhamil

Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"

[ Post a follow-up to this message ]

Richard.L.Hamilton@mindwarp.smart.net (Richard L. Hamilton) writes:

>Is AT_SUNW_AUXFLAGS a Solaris 10 thing?  I can't find it in
>any of the sys/aux*.h on Solaris 9 (nor anywhere in the
>/usr/platform/*/include trees).

Uhm, yes.  It replaces the information the AT_*ID variables
where supposed to convey.

Casper

[ Post a follow-up to this message ]