From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17237 invoked by alias); 5 Dec 2014 13:38:47 -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 17226 invoked by uid 89); 5 Dec 2014 13:38:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: glazunov.sibelius.xs4all.nl Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 05 Dec 2014 13:38:43 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id sB5Dcbg7007690; Fri, 5 Dec 2014 14:38:37 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id sB5Dcauf016922; Fri, 5 Dec 2014 14:38:36 +0100 (CET) Date: Fri, 05 Dec 2014 13:38:00 -0000 Message-Id: <201412051338.sB5Dcauf016922@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: dtaylor@usendtaylorx2l.lss.emc.com CC: brobecker@adacore.com, gdb-patches@sourceware.org In-reply-to: <16730.1417451430@usendtaylorx2l> (message from David Taylor on Mon, 01 Dec 2014 11:30:30 -0500) Subject: Re: RFA bug fix -- x86-64 stabs and deprecated fp register References: <3508.1416603484@usendtaylorx2l> <20141130152036.GC4882@adacore.com> <16730.1417451430@usendtaylorx2l> X-SW-Source: 2014-12/txt/msg00136.txt.bz2 > Date: Mon, 01 Dec 2014 11:30:30 -0500 > From: David Taylor > > 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. We deprecated the concept of a frame pointer "register" more than a decade ago. There really isn't such a register on many architectures. On amd64 %rbp is available for the compiler to use for whatever purpose it sees fit. Reintroducing a real frame pointer register in the amd64-tdep.c code would be a mistake. The set_gdbarch_deprecated_fp_regnum() function has "deprecated" in its name for a reason. > 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. In GDB there always is a frame. A frameless function is a function that doesn't set up its own frame but re-uses the frame set up by its parent. So that matches "would be the frame pointer for the most recent function that had a frame". > But, my case is different from > > print $fp > > . It's more like: > > print foo > > where the debug information says foo lives at $fp - 24. The question here is how your debug format actually defines $fp here. For DWARF2 this is reasonably well defined. It has the concept of a call frame address CFA and provides enough information to reconstruct that address. For STABS this isn't well defined. Hopefully it matches GDB's idea of "frame base", which is what $fp represents. Few of us have really looked at the STABS code in GDB in the last decae. The mainstream Open Source world moved to DWARF2 long ago, and there is a substantial amount of bitrot in the STABS-related code, both on the producer (GCC) and consumer (GDB) side. But judging from what you write here: > 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. This seems to suggest that the real bug is in GDB's STABS code. It should probably encode the address of your variable as being LOC_LOCAL, in which case the address would be calculated as relative to the "frame locals" address which for most architectures (including amd64) is the same as "frame base". ... > 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. The problem here is that by choosing to use STABS on amd64 for your platform you're now so far behind the curve that there's basically nobody around with enough knowledge to help you out. All I can say to you is that your suggested fix isn't the right approach.