From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23007 invoked by alias); 8 Oct 2003 23:25:05 -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 23000 invoked from network); 8 Oct 2003 23:25:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Oct 2003 23:25:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h98NP4M13377 for ; Wed, 8 Oct 2003 19:25:04 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h98NP4c06779 for ; Wed, 8 Oct 2003 19:25:04 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h98NP2dT032120; Wed, 8 Oct 2003 19:25:03 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 5D2A32CCB2; Wed, 8 Oct 2003 19:36:01 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16260.40801.147331.587525@localhost.redhat.com> Date: Wed, 08 Oct 2003 23:25:00 -0000 To: Roland McGrath Cc: Andrew Cagney , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: <200310082147.h98Llq7K012173@magilla.sf.frob.com> References: <3F847AF4.8090409@redhat.com> <200310082147.h98Llq7K012173@magilla.sf.frob.com> X-SW-Source: 2003-10/txt/msg00276.txt.bz2 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_ > 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