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


Roland McGrath writes:
 > > 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.
 > 

If the AT_ENTRY value is correct for PIE, gdb will need it.  Gdb right
now assumes that the main executable is marked as EXEC to find the
entry point, and this doesn't hold for PIE.

 > > - 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

This is what I understood. So that it will work for remotes too.

 > 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",

The target lookup method will invoke the to_query method (i.e. if
remote, it will use the remote protocol query feature). This target
lookup method will also know what tag to look for.

 > 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).

You maybe are thinking that the tag is a parameter? If so the
return value will need to differ depending on what you are looking
for, and you will need a void* parameter (yuck!).

As I understood it, you will have a to_get_entry_point() and a
to_get_vsyscall_entry(), which then will query the target (via
to_query) for the auxv vector blocks and "parse" that.

elena


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