Re: unwind support for Linux 2.6 vsyscall DSO

[Andrew Cagney <ac131313@redhat.com>]

>> > There should be an iterator over the entries in the /proc/pid/auxv
>> > file with a callback that processes each entry. So that the iterator
>> > could be used not just for finding the AT_SYSINFO_EHDR entry. 
> 
>> 
>> Ok, an iterator interface is fine with me, just marginally less efficient
>> than the searcher when only one tag is actually used (and more efficient if
>> many tags are used).  (I had not proposed any function that would be useful
>> solely for AT_SYSINFO_EHDR, though that was one of Jim's early
>> suggestions.)  If others agree this is the right interface for a target_ops
>> addition, I will write that patch.
> 
> 
> Actually, I think this is not as useful an interface as one that fetches
> the whole block for you.  There is another use for this call besides the
> Linux-specific AT_SYSINFO_EHDR check: gcore.  We want gcore to produce
> NT_AUXV notes in core dumps so that those core dumps can be used to extract
> whatever AT_* information we could extract from core dumps written by a kernel.
> 
> This is easy to add either way, but is cleaner, simpler, and more efficient
> if it just writes the whole block uninterpreted than if it dissects and
> reassembles it.

For this to work, there will need to be mechanisms that:

- unpack an architecture's auxv
- pack an architecture's auxv
- transport the auxv from the target, to GDB.

The problem then is how to arrange these mechanisms so that they 
integrate well enough to work both native and cross (i386 on amd64 is 
considered a cross), be consistent with other gdb mechanisms and direction:

target vector xfers via an iterator:
- the low native code would be using the unpack method
- the PIE and VSYSCALL code would be very simple
- the CORE file code would need the pack method
- the low remote could on-demand read the data

target vector xfers raw data:
- the low native code would be simple
- the PIE and VSYSCALL code would need to use the unpack method
- the CORE file code would just write out the data
- the low remote code would, either be locked into transfering raw 
bytes, or be forced to use the pack method

Also, ...

In my way earlier post, I also suggested "remote I/O' - a generic 
mechanism for accessing arbitrary target data.  Looking through the 
target vectore I see there is already "to_query()".  The original intent 
of to_query was to handle exactly this sort of problem - pushing data 
anonymously through the target vector.   The auxv fetch, with a large 
bit of a struggle, could even be implemented using to_query.

So?

I've strong reservations towards adding redundant functionality to the 
target vector.  However, I also note that the existing to_query method 
isn't sufficient.

So I can see either an iterator, or an update to to_query being added to 
the target vector.  Given that the iterator is a given, that might be 
the safest starting point - let the target maintainer go through and 
clean up to_query.

thoughts,
Andrew