This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unwind support for Linux 2.6 vsyscall DSO


- 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]