From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30760 invoked by alias); 3 Dec 2014 03:50:32 -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 30748 invoked by uid 89); 3 Dec 2014 03:50:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 03 Dec 2014 03:50:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1AD9B116729 for ; Tue, 2 Dec 2014 22:50:28 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w0h1lRCRzFEM for ; Tue, 2 Dec 2014 22:50:28 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A2777116701 for ; Tue, 2 Dec 2014 22:50:27 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 6709D46B65; Wed, 3 Dec 2014 07:50:24 +0400 (RET) Date: Wed, 03 Dec 2014 03:50:00 -0000 From: Joel Brobecker To: David Taylor Cc: "gdb-patches@sourceware.org" Subject: Re: RFA bug fix -- x86-64 stabs and deprecated fp register Message-ID: <20141203035024.GJ4882@adacore.com> References: <3508.1416603484@usendtaylorx2l> <20141130152036.GC4882@adacore.com> <16730.1417451430@usendtaylorx2l> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16730.1417451430@usendtaylorx2l> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-12/txt/msg00051.txt.bz2 > 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. I don't know if it's me who used the wrong technical term, or if the terminology is misleading, but for me, a frameless function was meant to mean a function which does not use the frame pointer. But, to me, functions always have a frame, even if maybe in some case perhaps it is possible for their frame to have zero data in it. But in any case, there is always a frame address, and that's what $fp means to me. > 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. Sorry about that, but I personally have been the busiest I have ever been at work for the last few months. And I have a feeling that others have been too. The only tip I can offer to prevent this from happening is to ping us. Typical protocol we recommend is 2 weeks after submission and every week thereafter. It's sad that it has to be this way, but we have to remember that we are all volunteers trying to do their best. At the moment, I am taking time away from work just to research further and answer you. > 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. [...] > 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. It's actually not a question of having a register or no register. We were able to make this work without your patch before, and I just tested again today and it worked for me. I invite you to first take a look at findvar.c:default_read_var_value, which eventually calls frame.c:get_frame_locals_address. This function then "sniff"es the code to determine which base unwinder to use. And normally in your case, it should probably find amd64-tdep.c:amd64_frame_base. That's the vector which is going to use to compute the "frame_id" object corresponding to your function's frame. And of particular interest in your case is the "this_local" field which is expected to query the frame to return the frame's base address. In your case, it should probably be amd64_frame_base_address which, slightly simplified, returns the frame->cache->base. And going back further, you'll find that the frame cache is computed by amd64_frame_cache, which is a wrapper around amd64_frame_cache_1, which uses prologue parsing to determine the frame's base address. I am guessing that this is where you need to look. -- Joel