From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7737 invoked by alias); 24 Aug 2012 12:11:11 -0000 Received: (qmail 7586 invoked by uid 22791); 24 Aug 2012 12:11:04 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,TW_JV,TW_XJ X-Spam-Check-By: sourceware.org Received: from mms2.broadcom.com (HELO mms2.broadcom.com) (216.31.210.18) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Aug 2012 12:10:50 +0000 Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 24 Aug 2012 05:09:16 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB02.corp.ad.broadcom.com (10.9.200.133) with Microsoft SMTP Server id 8.2.247.2; Fri, 24 Aug 2012 05:09:57 -0700 Received: from [10.177.73.50] (unknown [10.177.73.50]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id CB46F9F9F5 for ; Fri, 24 Aug 2012 05:10:34 -0700 (PDT) Message-ID: <50376F3B.1080407@broadcom.com> Date: Fri, 24 Aug 2012 12:11:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "gdb-patches@sourceware.org" Subject: PATCH: error reading variable: value has been optimized out Content-Type: multipart/mixed; boundary=------------050500030808010203070708 X-IsSubscribed: yes 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 X-SW-Source: 2012-08/txt/msg00715.txt.bz2 --------------050500030808010203070708 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 5718 I found some behaviour that has changed, I believe, for the worse. I have found an example where, in the backtrace, gdb used to say this: #0 0x0000000000400504 in function () #1 0x00000000004004fc in broken (operand0=, operand1=) at bad.c:10 #2 0x00000000004004e5 in main () at main.c:4 But now gdb says this: #0 0x0000000000400504 in function () #1 0x00000000004004fc in broken (operand0=, operand1=) at bad.c:10 #2 0x00000000004004e5 in main () at main.c:4 We now get an error about the value being optimised out. I believe this should not be marked as an error as the value is quite legitimately no longer available. At the end of this email is a patch to restore the old behaviour. What follows here is a description of what causes the new behaviour. [ Using git clone from git://sourceware.org/git/gdb.git ] Things first changed with commit 25993ce40950a8b34b31efd49790a16be3d5c519 (http://sourceware.org/ml/gdb-cvs/2011-07/msg00184.html), after this the backtrace looked like this: #0 0x0000000000400504 in function () #1 0x00000000004004fc in broken (operand0=value has been optimized out ) at bad.c:10 #2 0x00000000004004e5 in main () at main.c:4 Clearly things went a little off the rails at this point, I think the old "" is better than the new "value has been optimized out" text, but it doesn't really matter, as things changed again with commit 3d0a5ee6551a1f2036a574f7802c1abc47eada41 (http://sourceware.org/ml/gdb-cvs/2011-09/msg00043.html), the behaviour is now: #0 0x0000000000400504 in function () #1 0x00000000004004fc in broken (operand0=, operand1=) at bad.c:10 #2 0x00000000004004e5 in main () at main.c:4 We get operand1 back again, along with the error message text. The example given by Jan when proposing the patch (http://sourceware.org/ml/gdb-patches/2011-08/msg00575.html) was this, "", in this case the format seems fine, there really was an error while reading the variable, however, in the example I have, there was no _error_, it's just the variable really has gone. I suggest then that the behaviour we have arrived at is a regression, and we should try to get back to a situation where, for my optimised out variables we see the original behaviour, but in the example Jan gave, we see the new error message style behaviour. The test attached (bad-bt.tar.bz2) is fairly contrived, and is x86 specific, but hopefully it's good enough to allow people to reproduce the error if they want to. I'm happy to discus the test if anyone things it's not valid. To run the test, tar -xjvf bad-bt.tar.bz2 cd bad-bt make check GDB= # This will run gdb and show the backtrace... When gdb tries to figure out where the variable is we eventually end up in dwarf2loc.c:dwarf2_evaluate_loc_desc_full, this tells us that at the address in question the variable is in a register, we then call findvar.c:value_from_register, which calls findvar.c:read_frame_register_value, this then calls get_frame_register_value followed by value_contents_copy. The problem is that value_contents_copy throws an error if the value returned by get_frame_register_value is optimised out, as it can quite legitimately be if a younger frame has marked the register in question as undefined. There is currently only one user of read_frame_register_value, which is the path I just described, I suggest then that we change the behaviour of this function to mark the whole result value as optimised out if any of the registers read to acquire the value are optimised out. I've included the patch do do this below. Looking through, value.c is seems there might also support for having values partially optimised out, this would seem like a better solution, but I'm not sure the right way to hook this in, if anyone would like to offer suggestions I'm happy to create a new patch, alternatively, this could be improved on later... Ok to commit? Or is more work required? Cheers, Andrew gdb/ChangeLog 2012-08-24 Andrew Burgess * findvar.c (read_frame_register_value): Mark the result value as optimized out if any of the input registers have been optimized out. diff --git a/gdb/findvar.c b/gdb/findvar.c index 66bcebe..ec9dde7 100644 --- a/gdb/findvar.c +++ b/gdb/findvar.c @@ -677,7 +677,10 @@ default_value_from_register (struct type *type, int regnum, /* VALUE must be an lval_register value. If regnum is the value's associated register number, and len the length of the values type, read one or more registers in FRAME, starting with register REGNUM, - until we've read LEN bytes. */ + until we've read LEN bytes. + + If any of the registers we try to read are optimized out, then mark the + complete resulting value as optimized out. */ void read_frame_register_value (struct value *value, struct frame_info *frame) @@ -703,6 +706,12 @@ read_frame_register_value (struct value *value, struct fram struct value *regval = get_frame_register_value (frame, regnum); int reg_len = TYPE_LENGTH (value_type (regval)) - reg_offset; + if (value_optimized_out (regval)) + { + set_value_optimized_out (value, 1); + break; + } + /* If the register length is larger than the number of bytes remaining to copy, then only copy the appropriate bytes. */ if (reg_len > len) ( --------------050500030808010203070708 Content-Type: application/octet-stream; name=bad-bt.tar.bz2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=bad-bt.tar.bz2 Content-length: 3453 QlpoOTFBWSZTWblE9IcADdN/pP74jARed///f7f/sP////4AIIABgAhgDGuN tNA+ztG63bADbhx3c0Od2g1oF2AHQASRJkQFNoZTxPQmUwGpiBpppkNBoyAA 0aAyAJTQgKTU8FTeRT09FAPSADTRoNAAAABoAA4NGjQNBoDJiAyNDIAA00yA AAYIACTSkIg1PU1DaPUTT1ANAGmnqMg0ABoANGgAekODRo0DQaAyYgMjQyAA NNMgAAGCAAiUJMmTQCCmzRMmqeyo09RoMgGRpk9Q0AAPUAek5QKv+8/HNycL voz40ajD1CQDOMzJJqqSSWnp6zT9Q/YIAhmbNaVfqmtOy9niDggMjBkBAA4F jH6FGAFjARA+k7z0GTbJ+ZYH1jBgrEEEUwQJ3ZDmsJCsCAayaoaOgNtUBEkr BEgwSDlR7rA4z8fvRaxuU158FHNfM43GvUt1YLBS+Cd6IxGzZprch554wUGI IJFmDZnvOmd3JLCUXED1OUTXkvsNNym10OG77jeLRDRXbrsN93OkRw6zkGzY 6kwi2btowR+1jRGwgW927kGDbrp4l9cVkw9yGmBPeLKpGwpaPwIK08GN1WoN nGn5iUhLh12R6wrb+GOO2zQVNeq4awKdilkqcbjSUmdnoOiZx8cMwtGJsFxu mG5dz9FnvSgtkzxqPa1IaEQQSLMGNS1umd3JLCUXED1OgTXkvuNNynKqnI+V GB3EFUlqu7GVzKrIUK5xE7aVZEItm7aMEdNjRGwgXO7cYMG3XTsX1xWTD3Ia YE94sqkbClo6SCtOmN1WoNnGnpJSEuHX3NwkBxriB+KgqbxizdHjJyrFlYiE 0HMZAqKiZzUcdXJv4nLkdld3WhHcPOYp5IRUDZEP8ARFdEUQ6cq92NBDJka7 JBDPLmdiwRtuRz570oMsVkYR0NaQmsINiDVC67hF0rqKTgD8itq8NUbX3sMG MVqRFoWHJV5GnOftPnOlDi9Hz5vcXw0ngmkDhHjRSlZbbEEElKHQIOxSCpIg ge54Ln9Hz9ta1r2e7J34SJ0tk4d/dDbbtBxaoCYklgsRGCMzYUagGSTEECjA qSDBARRJYwwUwYBRUxQhS2FGGMdPcGZ45A0RE5n0YqxcOMuUCoIiHNCPHlyV ytfzOflPIIgxh0rfAad/hbEdspUvquVL2P4vz+Gcbldzl8Z0DXoXPFduaNeA /J2du7sc1mvUrOdJ2w7XzjdaMmlKUrJMRJDmqT8OaXIBtJlAOocBppFXQGVF VV+Ylqr1g5365ELJZIeJKSF5AfWpCR16fFPp+OaeWoS2dLOFupCrgllC6WWL uqbJrsbxkIGEY3Riqdg1G42whwTYcVERGULQpaoUt2ydw8AhZwM8nFh0BmoO EO0Go6ufIW0tpbS2ltO5GJjGClESlpZbS0stpiYiGIjXEtRi2W0tpbTEYjJg wUpSltKUpbQtWlpZgRDAwMDDBvE0zzVtraSQYFJIdHJZMsKuVqqqqqquDGZl kqqqqqqkAZAHwutpdRdhnogTWUCaZuQTLIJVEtqpBIW1VVCISlljGIjGKxiq qsjIiIiqiW1VtliJbLLQKBCESJEIhct6jb5fh0et/JQu+XO1rExqPrhWwmUc NAYvjlCV64BvjuwC0DcR7GMeSat9JnwJiqTB7pWYYfLtQOQJIYyi+ZrmXwmK pMGSsww+XagZBvTIBDsrVtLTBxZ2+wEy+4w44758vWAN5Wo7a/KO92gGuuym ZAe0YAl8vo26m62nfvieFdsA6u7tS97xN636iTf0DJDAmBkkgwWIjBEkiMkF BggCrFCRgkiIKsjEgqoxRScpSwgjBEIpz+mb26wN9hRJzk6mqmmdgaMKEHRD R6jIKuAD6jrIT61w7Q0KaCDnz0KQgXgILfQAiMRRJgYvVxyAajA5142pytXz UbdzypRMu1DSc/Yw9rV7SE13Z2qOKlIlCajs7UHPzgg61GISW8IkDW/I/zgY Pe0uWZG52AEy16tcqVpXyLx4acCrdShIyNKUJGG7Kh6lqWoB2sWBrDFwE40X eENEOWNY1QOeTRexOCqZryBTLhcybQ0TilFmXupUy84HRYsQI0ASFpPohjBg khMlcfbZuSNBZpXfs0dbAytUglxx02CYgm7luRtUAkeiIwmcRVIN1wwISQOQ Mjn7y2Hl544VVVltC5u/zssx5WTOYqqqy2hdHTTLMTSIU17xoYNqyHEgo2zh CatQ5kQjIr7H3OIYYcEEErn+RRE+gVdoHxeSfzMV0ifbsF51PpZIQhBEuNRw BJ3jIDZ2BEVjEVYoqIkIQJGSFgcQSnfiA11rES+rkwhAkIQJCVBsrzGedCHi f0HUJoVPdPYDVLhALQFdIMBdUAT8JifH0BxHx2bPYHyAew3gc37Sa3HGhoKp YrtEvUZJJBkiPOWYJiPSWB9+i3HIPzr+UT5saP7DlQEqEBiBOBshLgvGQCIF 8yxOcQLfSFu8GP3Iy0y/XvnIS8+I/EIa1feMcqjIbAN5NOkeXL4S61vgXcvZ xiTC448tkAIdE5u/y/3zd/+vK17Txjr4xgiX5fxA8kSibgv7gPq4SFdIeFZK thOCIf8yE6xU+MiEIgPmDwpQKeFNghpbhoegIZ57rZd2z9VTbXjgbs7gdIyE BnEoYAPrN8ZPHtsUuKANCCXwX0kaDpy2tnfwD3giEGECEIHDAxNRQ9r/U9Kb 4BIEIhEgJ8Hlx8y+VKLS5G/romEAkCEQiQEqZadPNqIGGouFRRQt87WQCGuE Dr9WBNpoZafHShuLSARfvlU0NJpG8/TpA8yvMkDSBYoxkZwaqB9LB4nXy4yw 9D1NeIQ85zidaaxMHsLp3z/xA9GAo64IHZkERDNE0ZyXHBTz1dFBbPFwIb8K c8x3wxL+oXemruTZZbGAmwE1PR92npNaJ5oAYGrf4onDQUd5tsZkpUA2XEqc UuvTSAoQMy4XaO6hxeIhYICBpsIXjnzdOL1mZeruNVDcbHgUB6CsKLrlCK53 gwqBYL6XSvAvCsQuWH2aXIugQIJBAoXNcDzD9gdg8XpHmMTA0yMCV6ZI9BCN AOmumUAeONjeidrBCxiCGgECHMo5l8J6PYWNg9UnuUSkGNKMgw1m4+csOJCK TNNKnA71BAsNIETFVe8krAolGciFsphSxcBn2qYgmRfU0+CpeAUQ9o6sDZzg bjkBYpErAek16QqFjDQg6gN7iY2UuGg4KHaXgbuYvBMzhvurx3+GRAsUkNVO utCS6Ts3gUAvFdtVLupBHpLXal4bUy8FJFISSd7ecd3ciVivI0bDKCmhEuLG J/kQbuRDmOIh4cyIZy/ABQ5N/Wj1GgD5Idh7QPnA1bQMhDh0zvtkXB3T5lEA kESwIZGpBHo8SGR9+EVf/i7kinChIXKJ6Q4= --------------050500030808010203070708--