From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18808 invoked by alias); 6 Feb 2014 19:03:58 -0000 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 Received: (qmail 18799 invoked by uid 89); 6 Feb 2014 19:03:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2014 19:03:57 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s16J3twD027118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Feb 2014 14:03:55 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s16J3r1Z013384; Thu, 6 Feb 2014 14:03:54 -0500 Message-ID: <52F3DC99.8070209@redhat.com> Date: Thu, 06 Feb 2014 19:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [PATCH/RFC] Parsing auxv entries References: <201402041441.s14Efx91011969@glazunov.sibelius.xs4all.nl> In-Reply-To: <201402041441.s14Efx91011969@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00120.txt.bz2 On 02/04/2014 02:41 PM, Mark Kettenis wrote: > The diff below adds a gdbarch method to parse auxv entries. The > parsing code currently lives in the target_ops vector, and this poses > a problem. Because default_auxv_parse() implements parsing of the > non-standard auxv entries used by Linux (where the type is stored in a > 'long' instead of an 'int'), it doesn't work on 64-bit big-endian > targets that do follow the SVR4 layout. I've worked around this by > overriding to_auxv_parse in inf_ptrace_trace() for native BSD targets, > but that means the core_ops target is still broken. And as we build > binaries as PIE by default on OpenBSD now, where auxv parsing is > essential to find out the load address of the executable, reading core > dumps on our 64-bit big-endian platforms is pretty much broken right > now. And overriding to_auxv_parse for the core_ops target is painful. > > I believe gdbarch is the right place for this functionality. On many > platforms the memory layout of the entries is consistent across the > various sources. > But there may be some issues with running 32-bit > binaries on 64-bit systems in relation to things like /proc/*/auxv. I > suppose to_auxv_parse was designed to solve such problems, although I > fail to see how the current implementation would work in the scenario > of running 32-bit binarie on a platform where /proc/*/auxv provides > the auxv entries in 64-bit format. Yeah. See the Solaris version: #if defined (PR_MODEL_NATIVE) && (PR_MODEL_NATIVE == PR_MODEL_LP64) /* When GDB is built as 64-bit application on Solaris, the auxv data is presented in 64-bit format. We need to provide a custom parser to handle that. */ static int procfs_auxv_parse (struct target_ops *ops, gdb_byte **readptr, gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) { > > Thoughts? OK? Hmm, thoughts then. gdbarch does seems the right place, in principle. Though things in practice don't look that simple. Consider for example a 32-bit Solaris gdb, connected to a 64-bit gdbserver. In that case, the auxv data is presented to gdbserver in a 64-bit format, and then in turn that's what gdbserver sends back to GDB in response to TARGET_OBJECT_AUXV. GDB won't be able to figure out which layout of auxv it's looking at, unless perhaps it looks at the auxv block size (ewwwww), or explicitly asks the target/server which variant it sends. Not sure what the real proper fix for this would be. Several options I see. There might be more or even better ones. #1 - Install a solaris-specific gdbarch parse auxv hook that has gdb ask the target which variant of auxv is handed to gdb to work with. #2 - Hide the fact that the auxv data is presented differently depending on the bitness of the superior, by making the target do layout translation when returning the TARGET_OBJECT_AUXV object (like done with TARGET_OBJECT_SIGNAL_INFO on Linux). #3 - Hide the fact that the auxv data is presented differently depending on the bitness of the superior, by making the target always translate the auxv block to a host and target independent format that the core consumes (xml?). #2 seems tempting; though so does #3, a little. Dunno, #1 does too, just a little, perhaps not. And PowerPC has a similar issue: https://sourceware.org/ml/gdb-patches/2009-01/msg00440.html And that shows that we can't move the auxv parsing to gdbarch by default on Linux either. At least, not if we don't consult the target before the gdbarch hook. But then, it sounds like 32-bit gdb against 64-bit gdbserver on ppc might be similarly broken in some scenarios. #3 above starts sounding a little better than #2. So I swing back -- thought? :-) > > > 2014-02-04 Mark Kettenis > > * gdbarch.sh (parse_auxv): New. > * gdbarch.h: Regenerated. > * gdbarch.c: Regenerated. > * auxv.c (target_auxv_parse): Call gdbarch_parse_auxv if provided. > > diff --git a/gdb/auxv.c b/gdb/auxv.c > index dd13237..dcc6345 100644 > --- a/gdb/auxv.c > +++ b/gdb/auxv.c > @@ -269,8 +269,12 @@ int > target_auxv_parse (struct target_ops *ops, gdb_byte **readptr, > gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp) > { > + struct gdbarch *gdbarch = target_gdbarch(); > struct target_ops *t; > > + if (gdbarch_parse_auxv_p (gdbarch)) > + return gdbarch_parse_auxv (gdbarch, readptr, endptr, typep, valp); If this proceeds, can you please rename the hook in accordance to the target method? That is, gdbarch_auxv_parse rather than gdbarch_parse_auxv, so that greps have a better chance of hitting both? -- Pedro Alves