This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: unwind support for Linux 2.6 vsyscall DSO
- From: Roland McGrath <roland at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: Wed, 8 Oct 2003 14:47:52 -0700
- Subject: Re: unwind support for Linux 2.6 vsyscall DSO
> 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).