From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3201 invoked by alias); 7 Oct 2003 04:28:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3192 invoked from network); 7 Oct 2003 04:28:15 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 7 Oct 2003 04:28:15 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 20AF5357B; Mon, 6 Oct 2003 21:28:14 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h974SDN2019380; Mon, 6 Oct 2003 21:28:13 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h974SDFm019376; Mon, 6 Oct 2003 21:28:13 -0700 Date: Tue, 07 Oct 2003 04:28:00 -0000 Message-Id: <200310070428.h974SDFm019376@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Andrew Cagney's message of Monday, 6 October 2003 23:53:20 -0400 <3F8238B0.50409@redhat.com> X-Windows: warn your friends about it. X-SW-Source: 2003-10/txt/msg00161.txt.bz2 > - 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).