From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29450 invoked by alias); 18 Sep 2013 17:35:25 -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 29440 invoked by uid 89); 18 Sep 2013 17:35:25 -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; Wed, 18 Sep 2013 17:35:25 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8IHZ96E023765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Sep 2013 13:35:09 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r8IHZ78S029238; Wed, 18 Sep 2013 13:35:08 -0400 Message-ID: <5239E44B.7030704@redhat.com> Date: Wed, 18 Sep 2013 17:35: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: Eli Zaretskii CC: aburgess@broadcom.com, gdb-patches@sourceware.org, mark.kettenis@xs4all.nl Subject: Re: [PATCH+DOC] Print registers not saved in the frame as "", instead of "". 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> In-Reply-To: <83zjram6sw.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00613.txt.bz2 On 09/18/2013 05:30 PM, Eli Zaretskii wrote: >> Date: Wed, 18 Sep 2013 16:54:27 +0100 >> From: Pedro Alves >> CC: gdb-patches@sourceware.org, Mark Kettenis >> >> Eli, I've added NEWS and documentation changes to this patch. >> Are those OK? > > Almost. > >> +* GDB now shows "" when printing values of registers that >> + have not been saved in the frame: >> + >> + (gdb) p $rax $1 = >> + (gdb) info registers rax rax > > Wrong formatting of what GDB prints. Blah. Bad copy/paste. Thanks. > >> +In some ABIs, some registers may not be preserved, or saved, across >> +function calls. It may therefore not be possible for @value{GDBN} to >> +know the value a register had before the call (in other words, in a > ^ > "the" Fixed. > >> +outer frame). Values of registers that @value{GDBN} can tell were not >> +saved in their stack frames are shown as @w{@samp{}}. >> + >> +However, if debug or unwind information is missing, @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. > > I don't understand the significance of the last paragraph. It's preexisting actually. I just added the "debug or unwind info" bit. But yeah, it's confusing. I _think_ I know what it's talking about. I think "makes no difference" refers to GDB assuming $reg in an outer frame is found at the same location as in the inner frame (that is, assuming the call clobbered register hasn't been clobbered yet). I've rewritten all this text now. What do you think? > Also, shouldn't we mention optimizations as (the main) reason for > registers being unavailable? I'm not actually sure how to say that. Not sure you actually always need optimization to see this in the debugger. But maybe we don't need to in this new version. :-) diff --git c/gdb/NEWS w/gdb/NEWS index af06a21..7c10cbb 100644 --- c/gdb/NEWS +++ w/gdb/NEWS @@ -15,6 +15,19 @@ * The "catch syscall" command now works on arm*-linux* targets. +* GDB now shows "" when printing values of registers the + debug info indicates have not been saved in the frame and there's + nowhere to retrieve them from: + + (gdb) p $rax + $1 = + + (gdb) info registers rax + rax + + Before, the former would print "", and the latter + "*value not available*". + * Python scripting ** Frame filters and frame decorators have been added. diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo index 60d2877..d122874 100644 --- c/gdb/doc/gdb.texinfo +++ w/gdb/doc/gdb.texinfo @@ -10031,10 +10031,21 @@ were exited and their saved registers restored. In order to see the true contents of hardware registers, you must select the innermost frame (with @samp{frame 0}). -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. +In some ABIs, some registers may not be preserved, or saved, across +function calls. It may therefore not be possible for @value{GDBN} to +know the value a register had before the call (in other words, in the +outer frame), if the register has since been clobbered 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. 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. 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. Values of +registers that @value{GDBN} can definitely tell from the debug/unwind +info were not saved in their stack frames and there's nowhere to +retrieve the original value from anymore are shown as +@w{@samp{}}. @node Floating Point Hardware @section Floating Point Hardware