From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11293 invoked by alias); 8 Oct 2003 21:47:58 -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 11278 invoked from network); 8 Oct 2003 21:47:54 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 8 Oct 2003 21:47:54 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 4D28C357B; Wed, 8 Oct 2003 14:47:53 -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 h98LlrN2012177; Wed, 8 Oct 2003 14:47:53 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h98Llq7K012173; Wed, 8 Oct 2003 14:47:52 -0700 Date: Wed, 08 Oct 2003 21:47:00 -0000 Message-Id: <200310082147.h98Llq7K012173@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 Wednesday, 8 October 2003 17:00:36 -0400 <3F847AF4.8090409@redhat.com> X-Shopping-List: (1) Audacious inhibitions (2) Quizzical bags (3) Clairvoyant removers (4) Encyclopedic ethical rail contraptions X-SW-Source: 2003-10/txt/msg00271.txt.bz2 > 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. > - 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 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", 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).