Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney <ac131313@redhat.com>]

>> - unpack an architecture's auxv
>> - pack an architecture's auxv
> 
> 
> This in fact differs with byte order and word size, not further by target.
> So a generic utility function suffices for this.  If the responsibility for
> packing and unpacking is in each target, they should all be able to use the
> same utility function and stay about as simple as the block-reading target
> code.  If the responsibility for unpacking lies with the caller of the
> target function, then the single utility function suffices for all callers
> (since then there is never a need for packing, only unpacking).

Unfortunatly, things aren't so simple :-(

Solaris:
#define AT_DCACHEBSIZE  10      /* smallest data cache block size */
#define AT_ICACHEBSIZE  11      /* smallest instruction cache block size */
#define AT_UCACHEBSIZE  12      /* smallest unified cache block size */
...

GNU/Linux:
#define AT_NOTELF 10    /* program is not ELF */
#define AT_UID    11    /* real uid */
#define AT_EUID   12    /* effective uid */
...

As with signals, the attribute indexes are per-os (and potentially per 
ISA).  So core code will need to define an OS independant set of enums 
and then map that onto the real numbers.

If I understand things correctly, the two driving needs are:

- being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
address>

- being able to obtain the entire AUXV so that it can be saved in a core 
file

Would a per-os (technically per-architecture) SVR4 auxv lookup method 
that was implement using a fixed to_query() work?

Andrew