From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6312 invoked by alias); 1 Dec 2014 16:30:53 -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 6301 invoked by uid 89); 1 Dec 2014 16:30:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 01 Dec 2014 16:30:50 +0000 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB1GUgF2010607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2014 11:30:43 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB1GUgF2010607 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com sB1GUgF2010607 Received: from mailsyshubprd53.lss.emc.com (mailsyshubprd53.lss.emc.com [10.106.48.28]) by maildlpprd51.lss.emc.com (RSA Interceptor); Mon, 1 Dec 2014 11:29:54 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sB1GUVSx014946; Mon, 1 Dec 2014 11:30:32 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 071585D9D78; Mon, 1 Dec 2014 11:30:30 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id F41CE5D909D; Mon, 1 Dec 2014 11:30:30 -0500 (EST) To: Joel Brobecker cc: "gdb-patches@sourceware.org" Subject: Re: RFA bug fix -- x86-64 stabs and deprecated fp register In-reply-to: <20141130152036.GC4882@adacore.com> References: <3508.1416603484@usendtaylorx2l> <20141130152036.GC4882@adacore.com> Comments: In-reply-to Joel Brobecker message dated "Sun, 30 Nov 2014 10:20:36 -0500." Date: Mon, 01 Dec 2014 16:30:00 -0000 Message-ID: <16730.1417451430@usendtaylorx2l> From: David Taylor X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd53.lss.emc.com X-SW-Source: 2014-12/txt/msg00018.txt.bz2 Joel Brobecker wrote: > David, > > On Fri, Nov 21, 2014 at 03:58:04PM -0500, David Taylor wrote: > > Sometimes when using STABS on x86-64 GNU/Linux, GDB does not know which > > register to use for the frame pointer and as a result offsets from the > > frame pointer are treated as absolute addresses rather than as > > offsets... > > > > This patch provides a default for when the debug information doesn't > > specify which register to use. > > > > We have seen this problem when debugging problems with a previous > > release of our software (I believe it was built with GCC 4.5.x, if that > > matters). > > > > There were no regressions on x86-64 GNU/Linux. > > > > 2014-11-21 David Taylor > > > > * amd64-tdep.c (amd64_init_abi): Set default frame pointer. > > I don't think your patch is correct, as it is going to affect > the outcome of... > > (gdb) print $fp > > ... for frameless functions compiled with DWARF2. See > std-regs.c:value_of_builtin_frame_fp_reg. > > If we were to apply your patch, it would unconditionally print > the contents of the %rbp register as the result, which is not > what we've been printing so far. For a frameless function, I would expect that $fp would be either or would be the frame pointer for the most recent function that had a frame or would just be %rbp. Since a frameless function has no frame, I would consider any of the three to be reasonable. I would also argue that it is an error to ask for the frame pointer of a frameless function, but that an error should not be thrown as the user shouldn't be expected to know that the function is frameless. But, my case is different from print $fp . It's more like: print foo where the debug information says foo lives at $fp - 24. There are functions where the debug information (STABS) specifies an offset from the frame pointer, but does not specify which register is the frame pointer. GDB currently decides to not use any register. It treats the offset as an offset from zero -- put another way, it treats it as an absolute address. Trying to find a local function variable at address -32 or -28 or -24 does not work. It is not mapped and even if it was, it wouldn't be the right address. Now, $rbp - 32 or $rbp - 28 is another matter entirely. GDB is currently saying ``I've been asked for the value of $fp, but I don't know which register is the frame pointer, so I don't have a value for $fp, and I'll just use 0''. The one line fix fixed real problems we had with STABS on our legacy systems. And has caused no problems with DWARF on our current systems. > I wish I could suggest another approach but I haven't had to touch > stabs support in several years, now. If you provided a bit more details > as to what actually happened in the debugger and where, I might be > able to help you better. When I first posted this bug report and fix months ago, it drew zero responses. (I noticed recently that it wasn't in so I sent another message.) At that time I could have told you more. I remember the symptom but not the details. For selected functions if you typed: print you would get an error because GDB thought that the variable had an address of -32 or -28 or -24 or similar (depending upon which local variable you selected). The ELF file was using STABS and when I debugged it, GDB said that the variable's address was a small offset from the frame pointer. It didn't know what to use for the frame pointer and ended up using zero. The fix merely decides what to do if you need a frame pointer and haven't been able to otherwise figure out what to use for the frame pointer -- use the traditional default frame pointer register %rbp. If you already have a frame pointer or do not need a frame pointer, nothing is changed. > > diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c > > index e69da01..5a68c33 100644 > > --- a/gdb/amd64-tdep.c > > +++ b/gdb/amd64-tdep.c > > @@ -3006,6 +3006,8 @@ amd64_init_abi (struct gdbarch_info info, struct gdbarch * > > gdbarch) > > set_gdbarch_ps_regnum (gdbarch, AMD64_EFLAGS_REGNUM); /* %eflags */ > > set_gdbarch_fp0_regnum (gdbarch, AMD64_ST0_REGNUM); /* %st(0) */ > > > > + set_gdbarch_deprecated_fp_regnum (gdbarch, AMD64_RBP_REGNUM); /* %rbp */ > > + > > /* The "default" register numbering scheme for AMD64 is referred to > > as the "DWARF Register Number Mapping" in the System V psABI. > > The preferred debugging format for all known AMD64 targets is > > -- > Joel