Re: unwind support for Linux 2.6 vsyscall DSO

[Elena Zannoni <ezannoni at redhat dot com>]

Andrew Cagney writes:
 > >> - 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>
 > 

Yes, this will definitely help with pie. More in general, the mechanism
that gdb uses to calculate the entry point can be changed to use this
info.

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

Yes, the whole thing can be dumped as a new note.

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

I think so, on Solaris some of the AT_* values in <sys/auxv.h> don't
match those in <elf.h> on linux and those in
gdb/../include/elf/elf.h. The AT_SYSINFO_EHDR seems to be 33 on all of
those, but other values are different. If we want to extend the auxv
handling to recognize more types, we may run into problems. 

elena



 > 
 > Andrew
 >