From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31160 invoked by alias); 8 Oct 2003 23:53:52 -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 31121 invoked from network); 8 Oct 2003 23:53:51 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Oct 2003 23:53:51 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7O7q-0005LN-Vr for ; Wed, 08 Oct 2003 19:53:50 -0400 Date: Wed, 08 Oct 2003 23:53:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO Message-ID: <20031008235350.GA20469@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200310070428.h974SDFm019376@magilla.sf.frob.com> <3F847AF4.8090409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F847AF4.8090409@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00277.txt.bz2 On Wed, Oct 08, 2003 at 05:00:36PM -0400, Andrew Cagney wrote: > >>- 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> > > - being able to obtain the entire AUXV so that it can be saved in a core > file > > Would a per-os (technically per-architecture) SVR4 auxv lookup method > that was implement using a fixed to_query() work? Sounds more or less good to me. I don't think we need a generic gdbarch method for querying auxv; more something like a gdbarch_auxv_entry_point () and a gdbarch_auxv_sysinfo_dso_address ()? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer