Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

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

> 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

You left out:

 - the pack method is required anywhere at all

> - the low remote could on-demand read the data

True.  FYI, the upper bound on real-world sizes of this data is 320 bytes.

> 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

You left out:

 - no pack method need actually exist

> - the low remote code would, either be locked into transfering raw 
> bytes, or be forced to use the pack method

I can't see why it would want to do anything else, since the low-level
mechanisms available to the remote stub will be in terms of raw bytes.

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

to_query is adequate if its calling interface is refined to include
returning an error if the buffer is too small and the caller trying again
with a larger buffer (or returning an allocated buffer, whatever).  Aside
from the general hokeyness of the letter and string operation selectors,
the fixed size of the result buffer is the only thing really wrong with it.

> So?

So how come noone else seems to know to_query is there? :-)

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

It's not too bad, i.e. right enough with a little fixing.  Moreover, it's
called in two places and implemented in two targets.  So changing it is not
going to be very hard.

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

What's not a given is the iterator being the lowest level facility
available.  That makes the corefile writing code clunky.  I really don't
see the rationale for choosing an iterator as the target vector interface
for aux vector fetching.  With to_query or slight modifications of it,
block-fetching is the straightforward interface to layer on top of that;
that is also the most practical thing to use.  I have no objection to doing
that, and would be willing to adjust the very few other uses of to_query
for a cleaned-up interface (though I cannot test them).