From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15441 invoked by alias); 15 Sep 2008 00:28:15 -0000 Received: (qmail 15432 invoked by uid 22791); 15 Sep 2008 00:28:15 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Sep 2008 00:27:31 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 19A5C390032 for ; Sun, 14 Sep 2008 21:06:01 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m8F0RWS21728712 for ; Sun, 14 Sep 2008 21:27:32 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8F0RPBD024288 for ; Sun, 14 Sep 2008 21:27:25 -0300 Received: from [9.8.5.193] ([9.8.5.193]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8F0RPlQ023907; Sun, 14 Sep 2008 21:27:25 -0300 Subject: Re: [PATCH/RFC] auxv entries From: Thiago Jung Bauermann To: Mark Kettenis Cc: gdb-patches@sourceware.org In-Reply-To: <200809142127.m8ELR9eX025288@brahms.sibelius.xs4all.nl> References: <200809142127.m8ELR9eX025288@brahms.sibelius.xs4all.nl> Content-Type: text/plain; charset=utf-8 Date: Mon, 15 Sep 2008 00:28:00 -0000 Message-Id: <1221438424.17278.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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/msg00326.txt.bz2 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; This is what I see in on ppc64-linux: > > This is not the layout that default_auxv_parse() uses though, which is > wrong for big-endian 64-bit systems. The attached diff fixes this, > making the assumption that a_val is "naturally" aligned. > > I have some slight worries though about how this ever worked on > big-endian 64-bit Linux systems, hence the RFC. > > > Index: ChangeLog > from Mark Kettenis > > * auxv.c (default_auxv_parse): Change code to reflect standard > auxv_t layout. > > Index: auxv.c > =================================================================== > RCS file: /cvs/src/src/gdb/auxv.c,v > retrieving revision 1.14 > diff -u -p -r1.14 auxv.c > --- auxv.c 11 Sep 2008 14:29:21 -0000 1.14 > +++ auxv.c 14 Sep 2008 21:20:03 -0000 > @@ -82,20 +82,22 @@ int > default_auxv_parse (struct target_ops *ops, gdb_byte **readptr, > gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) > { > - const int sizeof_auxv_field = gdbarch_ptr_bit (target_gdbarch) > - / TARGET_CHAR_BIT; > + struct type *builtin_int = builtin_type (target_gdbarch)->builtin_int; > + struct type *builtin_long = builtin_type (target_gdbarch)->builtin_long; > + const int sizeof_auxv_type = TYPE_LENGTH(builtin_int); > + const int sizeof_auxv_val = TYPE_LENGTH(builtin_long); > gdb_byte *ptr = *readptr; > > if (endptr == ptr) > return 0; > > - if (endptr - ptr < sizeof_auxv_field * 2) > + if (endptr - ptr < sizeof_auxv_val * 2) > return -1; > > - *typep = extract_unsigned_integer (ptr, sizeof_auxv_field); > - ptr += sizeof_auxv_field; > - *valp = extract_unsigned_integer (ptr, sizeof_auxv_field); > - ptr += sizeof_auxv_field; > + *typep = extract_unsigned_integer (ptr, sizeof_auxv_type); > + ptr += sizeof_auxv_val; /* Alignment. */ > + *valp = extract_unsigned_integer (ptr, sizeof_auxv_val); > + ptr += sizeof_auxv_val; > > *readptr = ptr; > return 1; > -- []'s Thiago Jung Bauermann IBM Linux Technology Center