Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland@redhat.com>]

> Unfortunatly, things aren't so simple :-(

Nothing in reality differs from what I've described.  I have already
mentioned the OS-specific nature of AT_* tag values.

> As with signals, the attribute indexes are per-os (and potentially per ISA).

Btw, these are tags, not indexes.  Referring to them as indexes might lead
people to write code that assumes things about the set of possible values.

> So core code will need to define an OS independant set of enums 
> and then map that onto the real numbers.

What for?  Examination of these values is OS-dependent.  I don't expect
that any OS-independent code will refer to any AT_* constants at all.

> If I understand things correctly, the two driving needs are:
> 
> - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
> address>

It's called AT_SYSINFO_EHDR.  As to AT_ENTRY, that is probably needed for
PIE support but that is so far just a guess on my part and AFAIK Elena has
not finished figuring out what is required.

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

Correct.

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

I am not entirely clear on what you mean here.  Do you mean a to_query
encoding of the read_aux_vector functionality, wherein the query returns a
block of bytes?  That is what I have been suggesting.  As I have said
before, the "lookup" work of extracting the value for a given tag number
has no OS-specific or machine-specific components beyond knowing target
word size and byte order.  If that is what you mean by "lookup method",
then no, there is no need for a per-OS function to do that.  The choice of
what tag numbers you're looking for and what you'll do with the values is
OS-specific (as is the interest to look at all).