From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16565 invoked by alias); 8 Oct 2003 23:10:26 -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 16556 invoked from network); 8 Oct 2003 23:10:26 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Oct 2003 23:10:26 -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 h98NAPM09406 for ; Wed, 8 Oct 2003 19:10:25 -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 h98NAPc02337 for ; Wed, 8 Oct 2003 19:10:25 -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 h98NAOdT030899; Wed, 8 Oct 2003 19:10:24 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 0179A2CCB2; Wed, 8 Oct 2003 19:21:22 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16260.39922.386746.598097@localhost.redhat.com> Date: Wed, 08 Oct 2003 23:10:00 -0000 To: Andrew Cagney Cc: Roland McGrath , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: <3F847AF4.8090409@redhat.com> References: <200310070428.h974SDFm019376@magilla.sf.frob.com> <3F847AF4.8090409@redhat.com> X-SW-Source: 2003-10/txt/msg00275.txt.bz2 Andrew Cagney writes: > >> - 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). > > Unfortunatly, things aren't so simple :-( > > Solaris: > #define AT_DCACHEBSIZE 10 /* smallest data cache block size */ > #define AT_ICACHEBSIZE 11 /* smallest instruction cache block size */ > #define AT_UCACHEBSIZE 12 /* smallest unified cache block size */ > ... > > GNU/Linux: > #define AT_NOTELF 10 /* program is not ELF */ > #define AT_UID 11 /* real uid */ > #define AT_EUID 12 /* effective uid */ > ... > > As with signals, the attribute indexes are per-os (and potentially per > ISA). So core code will need to define an OS independant set of enums > and then map that onto the real numbers. > > If I understand things correctly, the two driving needs are: > > - being able to extract the value of AT_ENTRY, and AT_LINUX_ address> > Yes, this will definitely help with pie. More in general, the mechanism that gdb uses to calculate the entry point can be changed to use this info. > - being able to obtain the entire AUXV so that it can be saved in a core > file > Yes, the whole thing can be dumped as a new note. > Would a per-os (technically per-architecture) SVR4 auxv lookup method > that was implement using a fixed to_query() work? I think so, on Solaris some of the AT_* values in don't match those in on linux and those in gdb/../include/elf/elf.h. The AT_SYSINFO_EHDR seems to be 33 on all of those, but other values are different. If we want to extend the auxv handling to recognize more types, we may run into problems. elena > > Andrew >