From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22858 invoked by alias); 15 Sep 2008 09:21:19 -0000 Received: (qmail 22849 invoked by uid 22791); 15 Sep 2008 09:21:18 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Sep 2008 09:20:40 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m8F9KWuu015525; Mon, 15 Sep 2008 11:20:32 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m8F9KVTI023217; Mon, 15 Sep 2008 11:20:31 +0200 (CEST) Date: Mon, 15 Sep 2008 09:21:00 -0000 Message-Id: <200809150920.m8F9KVTI023217@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: bauerman@br.ibm.com CC: gdb-patches@sourceware.org In-reply-to: <1221438784.17278.18.camel@localhost.localdomain> (message from Thiago Jung Bauermann on Sun, 14 Sep 2008 21:33:04 -0300) Subject: Re: [PATCH/RFC] auxv entries References: <200809142127.m8ELR9eX025288@brahms.sibelius.xs4all.nl> <1221438784.17278.18.camel@localhost.localdomain> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00335.txt.bz2 > From: Thiago Jung Bauermann > Date: Sun, 14 Sep 2008 21:33:04 -0300 > > (I'd really, really like to talk to the person who thought it would be a > good idea to make + a shortcut to send the message.) Heh > El dom, 14-09-2008 a las 23:27 +0200, Mark Kettenis escribió: > > Many, if not all, processor-specific ELF ABI documents have the > > following definition of auxv entries: > > > > typedef struct > > { > > int a_type; > > union { > > long a_val; > > void *a_ptr; > > void (*a_fcn)(); > > } a_un; > > } auxv_t; > > I have this in in ppc64-linux: > > typedef struct > { > uint64_t a_type; /* Entry type */ > union > { > uint64_t a_val; /* Integer value */ > /* We use to have pointer elements added here. We cannot do that, > though, since it does not work when using 32-bit definitions > on 64-bit platforms and vice versa. */ > } a_un; > } Elf64_auxv_t; > > So default_auxv_parse seems right to me. Hmm, so it looks like Linux doesn't follow the 64-bit PowerPC ABI here. At least version 1.7 of that spec has the "standard" form of the struct with a_type being an int. OpenBSD and Solaris both use the "standard" form, so I'd argue that Linux is the odd one out here. I'll see if I can come up with a diff that overrides the standard layout for 64-bit PPC linux.