From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30302 invoked by alias); 24 Sep 2013 13:43:18 -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 30293 invoked by uid 89); 24 Sep 2013 13:43:18 -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 13:43:18 +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-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8ODhDQs009730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 09:43:14 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8ODhBcP016673; Tue, 24 Sep 2013 09:43:12 -0400 Message-ID: <524196EF.8090107@redhat.com> Date: Tue, 24 Sep 2013 13:43: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> <5241805D.3020800@redhat.com> <52418BFA.6030405@broadcom.com> In-Reply-To: <52418BFA.6030405@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00851.txt.bz2 On 09/24/2013 01:56 PM, Andrew Burgess wrote: >>> 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). > > I guess the thing I'm struggling with is why would we /ever/ assume the > value in an inner frame is correct? "correct" depends on the definition. If we defined registers in frame > 0 the way I suggested in response to Mark, then they always are. Doing otherwise means assuming we know the ABI the outer and inner frames agreed on. There are a number of ways to get that wrong, like with assembly code, or even probably with gcc attributes or some JITs, meaning GDB will hide the value from the user behind , when it should not. Granted, not the _usual_ scenario, but I bet it's real. Yeah, can always be fixed in the unwind/debug itself. > Sure, for very shallow stacks on > machines with a non-small register set there's a reasonable chance the > value is correct, but in any other case I seriously don't see how taking > the value from an inner frame is any better than picking a random number. Again, it's a matter of definition -- "taking a value from an inner frame" just meant "if the unwind info doesn't say the register was saved, then assume that when the inner function returned, the register would still hold that value". > I think that if you print it "they" (users) will use it, assuming it's > correct. Given that I don't think it's correct I think we're likely to > be giving users miss-information. And here is where I'm wondering what sort of use do you think they'll be giving them. :-) GDB will still print for variables that happened to be live in such registers at the time of the call. If the functions involved are C or even higher-level language code, nothing changes, because indeed if the register is supposedly call-clobbered nothing in the caller will be expecting to find the old register value still in the register. But, when you're peeking into machine register values in the debugger you're going deeper than that. You're probably looking into mapping them to a disassembly of the machine code. In my mind, at this level, it's not strictly correct for GDB to assume any particular ABI -- best be driven by unwind info, and if the unwind info doesn't specify where the register was saved, at least give the user some useful value, rather than forcing her to go hunt for it in inner frames. (Again, I think both perspectives are reasonable. But if the always-print-registers route is harder to explain to other GDB developers, then that does hint that users wouldn't understand it either, which does favor the route.) -- Pedro Alves