From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10626 invoked by alias); 24 Sep 2013 12:07:00 -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 10617 invoked by uid 89); 24 Sep 2013 12:07:00 -0000 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; Tue, 24 Sep 2013 12:07:00 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com 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 r8OC6trn025469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 08:06:55 -0400 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 r8OC6rT1011763; Tue, 24 Sep 2013 08:06:54 -0400 Message-ID: <5241805D.3020800@redhat.com> Date: Tue, 24 Sep 2013 12:07: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: Andrew Burgess CC: gdb-patches@sourceware.org, Eli Zaretskii , Mark Kettenis Subject: Re: [PATCH] Always print call-clobbered registers in outer frames. References: <5200F55E.2050308@broadcom.com> <201308061318.r76DIMdd016369@glazunov.sibelius.xs4all.nl> <5200FECF.7030304@broadcom.com> <201308061541.r76FfYQN022875@glazunov.sibelius.xs4all.nl> <520142D9.4030304@redhat.com> <5208E3C8.7060107@broadcom.com> <5208E938.3080305@redhat.com> <201308122001.r7CK1862007934@glazunov.sibelius.xs4all.nl> <520E7255.7080206@redhat.com> <5211F25A.5070907@broadcom.com> <5228B15F.7060108@redhat.com> <5228B2D8.7060604@broadcom.com> <5237567C.8050406@redhat.com> <5239B2D8.4030403@broadcom.com> <5239CCB3.605@redhat.com> <83zjram6sw.fsf@gnu.org> <201309182047.r8IKlOGA010471@glazunov.sibelius.xs4all.nl> <83fvt1mems.fsf@gnu.org> <523B2D39.8060303@redhat.com> <523B4D48.3050206@redhat.com> <523C2B6F.4000007@broadcom.com> In-Reply-To: <523C2B6F.4000007@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00849.txt.bz2 On 09/20/2013 12:03 PM, Andrew Burgess wrote: > On 19/09/2013 8:15 PM, Pedro Alves wrote: >> Like this... >> >> -------------- >> Subject: [PATCH] Always print call-clobbered registers in outer frames. >> >> With older GCCs, when some variable lived on a call-clobbered register >> just before a call, GCC would mark such register as undefined across >> the function call, with DW_CFA_undefined. This is interpreted by the >> debugger as meaning the variable is optimized out at that point. That >> is, if the user does "up", and tries to print the variable. >> >> Newer GCCs stopped doing that. They now just don't emit a location >> for the variable, resulting in GDB printing "" all the >> same. (See .) >> >> The difference is that with binaries produced by those older GCCs, GDB >> will also print the registers themselves (info registers / p $reg) as >> "". This is confusing. > > I agree with you 100% on this, however, I feel we're merging two > arguments together here. The reason gdb prints is > really because values only support 3 states: available, unavailable, and > optimized-out, we use optimized-out for the DW_CFA_undefined state. > > What we really need is a new state, lets call it not-saved, we don't > necessarily need to have extra state inside the value object to model > this, we might (as in your original patch) be able to derive this state, > but this is a state that a register can be in. Luckily, I already have a patch that does that. :-) >> This patch makes GDB always follow this rule (which is what the >> heuristic unwinders usually do by default): >> >> The values of call-clobbered registers in the outer frame, if not >> saved by the caller, are defined as being the values the registers >> would have if the inner frame was to return immediately. > > You're right that most targets seem to follow this rule, which seems odd > to me, however I think that the rs600, s390, sh, and tic6x targets > don't, they set the call-clobbered registers to DW_CFA_undefined in > their dwarf2_frame_set_init_reg functions, this seems much more sensible > to me, assuming that call-clobbered registers have not been used seems > .... odd. Okay. Reading more code, and investigating the history behind it convinced me that that is indeed the direction GDB was currently heading. > >> >> The documentation is updated to more clearly explain this. >> >> IOW, ignore DW_CFA_undefined _when printing frame registers_, but >> not when printing variables. This translates to, if value of a frame >> register, comes out as optimized out (that's what "not saved" >> lval_register values end up as), fetch it from the next frame. > > I really think this is going to confuse users, we're basically saying > that call-clobbered registers are assumed to never be clobbered .... we > might get away with this from very shallow call-stacks, but for very > deep stacks this seems very unlikely, in which case, a user switches to > some outer stack and does "info registers", how does he know which > registers gdb has carefully retrieved and are correct, and which are > just random values fetched from some inner frame? I had toyed with something like Doug suggested. See my other reply to Mark. > My question then is, what makes you believe the inner, possibly > call-clobbered value is right? Nothing, of course. It's just a choice -- either assume it's right, and somehow warn the user it may not be right through some other means; or, assume it's not right, and hide the value from the user. If GDB is wrong, the user can still fetch the value, though it'll take more steps (up+p $reg+down, etc.). It might still be a good idea to provide an easier way to "flatten" the not-saved registers as convenience for that, not sure). (skipping answering some of the other points as I believe I've answered them in my other reply to Mark). >> -However, @value{GDBN} must deduce where registers are saved, from the machine >> -code generated by your compiler. If some registers are not saved, or if >> -@value{GDBN} is unable to locate the saved registers, the selected stack >> -frame makes no difference. >> +Most ABIs reserve some registers as ``scratch'' registers that don't >> +need to be saved by the caller (a.k.a. caller-saved or call-clobbered >> +registers). It may therefore not be possible for @value{GDBN} to know > > I think here you should say "Most ABIs reserve some registers as > ``scratch'' registers that don't need to be saved by the callee" > (callee, not caller). Indeed. > >> +the value a register had before the call (in other words, in the outer >> +frame), if the register value has since been changed by the callee. >> +@value{GDBN} tries to deduce where registers are saved, from the debug >> +info, unwind info, or the machine code generated by your compiler. > > I don't think this is correct either, we try to figure out where callee > saved registers are stored, but these are not the scratch registers, if > the scratch registers are needed by the caller then the caller will save > them, but the callee will just go ahead and use them. Similarly the > DWARF only tells us about callee saved registers. The caller saved > registers are now not mentioned in the DWARF as gcc has made sure that > no variables are live in these registers. Hmm. You're right, but only if you see a sequence/connection between the sentences. They're different paragraphs -- the second sentence is mostly preexisting, and I didn't mean to imply the GDB tries to figure out where caller-saved/scratch registers are. I'll rephrase it (in this or the patch, whatever we end up with. Thanks. > >> If >> +some register is not saved, or if @value{GDBN} is unable to locate the >> +saved register, @value{GDBN} will assume the register in the outer >> +frame had the same location and value it has in the inner frame. In >> +other words, the values of call-clobbered registers in the outer >> +frame, if not saved by the caller, are defined as being the values the >> +registers would have if the inner frame was to return immediately. >> +This is usually harmless, but note however that if you change a >> +register in the outer frame, you may also be affecting the inner >> +frame. > > I'd just like to pick up on the "harmless" here, I agree that it would > be "harmless" in the sense that if we did a return in gdb it would be > harmless; the register is callee clobbered, the caller either does not > care what is in the register after the call, or has code to restore the > value that it does care about. Right, that's what I was thinking. It'd be better to write that out explicitly. > From a debugging point of few though, I > suspect showing the wrong value might be far from harmless, No sure why. > and if this > patch is merged we need to draw attention to the fact that the more > "outer" the frame it you're looking at, the more likely call-clobbered > registers are to be wrong. Blah, what a rat hole. :-P :-) Please guys, re-confirm to me the direction you prefer seeing GDB follow, even after my reasoning further explained (I'm okay with either approach), and I'll update the corresponding patch's documentation bits with the suggestions you've sent. -- Pedro Alves