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
On Wed, Oct 08, 2003 at 05:00:36PM -0400, Andrew Cagney wrote:
> >>- 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?
Sounds more or less good to me. I don't think we need a generic
gdbarch method for querying auxv; more something like a
gdbarch_auxv_entry_point () and a gdbarch_auxv_sysinfo_dso_address ()?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer