Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Oct 06, 2003 at 11:53:20PM -0400, Andrew Cagney wrote:
> >>> 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

I think a pack method is overengineered.  Unlike, for instance,
register files, we never need to pack an arbitrary auxv array.
We're always just copying one that we've been given, exactly as-is.
I just see call for transport and query.

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

Hmm, yes.  The only problem that I see is the buffer-sizing one.  A
traditional problem in our interfaces, I think; the remote code avoids
the issue delicately.

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

While I won't argue about an iterator being useful, I think that the
target vector code would be clearer if we just had the raw buffer. 
Layer the iterator on top of it, instead of re-implementing the
iterator in every target.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer