unwind support for Linux 2.6 vsyscall DSO
Andrew Cagney
ac131313@redhat.com
Wed Oct 8 21:00:00 GMT 2003
>> - 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
More information about the Gdb-patches
mailing list