From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6173 invoked by alias); 21 Sep 2012 16:33:41 -0000 Received: (qmail 6132 invoked by uid 48); 21 Sep 2012 16:33:35 -0000 From: "aburgess at broadcom dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/14605] New: Display of partially optimised out variables from registers, using dwarf piece info. Date: Fri, 21 Sep 2012 16:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aburgess at broadcom dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2012-q3/txt/msg00377.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14605 Bug #: 14605 Summary: Display of partially optimised out variables from registers, using dwarf piece info. Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab AssignedTo: unassigned@sourceware.org ReportedBy: aburgess@broadcom.com Classification: Unclassified Created attachment 6645 --> http://sourceware.org/bugzilla/attachment.cgi?id=6645 An x86-64 assembler test file for this bug. Raising defect as requested in this gdb-patches mailing list thread: http://sourceware.org/ml/gdb-patches/2012-08/msg00715.html This bug is for a failure in the test gdb.dwarf2/dw2-op-out-param.exp that was added at the end of the above mailing list thread. If a variable is described by the DWARF as being split over multiple registers using DWARF piece information, but some of those register are marked as optimised out by a later frame then gdb incorrectly believes the value of those pieces is zero. Having a variable help in a register that is marked as optimised out by a later frame should probably be fixed in the dwarf producer, however, it is interesting in this case that gdb, without error or warning displays the *wrong* answer. However, no example of this bug has yet been seen in the wild. The test creates two call stacks: main --> struct_param_two_reg_pieces --> breakpt main --> int_param_two_reg_pieces --> breakpt In each function "struct_param_two_reg_pieces" and "int_param_two_reg_pieces" variables are placed in multiple register using piece information, and the function "breakpt" marks some of these registers as optimised out. The test file is x86-64 specific, download test.S, and assemble as: gcc -o test test.S Then run gdb as: > gdb test (gdb) break breakpt Breakpoint 1 at 0x4004fb (gdb) r Starting program: /projects/firepath_work/aburgess/tmp/gdb/test warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 Breakpoint 1, 0x00000000004004fb in breakpt () (gdb) c Continuing. Breakpoint 1, 0x00000000004004fb in breakpt () (gdb) c Continuing. Breakpoint 1, 0x00000000004004fb in breakpt () (gdb) set output-radix 16 Output radix now set to decimal 16, hex 10, octal 20. (gdb) set print frame-arguments all (gdb) bt #0 0x00000000004004fb in breakpt () #1 0x000000000040052e in struct_param_two_reg_pieces (operand0= {a = 0xdeadbe04deadbe05, b = 0x0}, operand1= {a = 0x0, b = 0xdeadbe00deadbe01}, operand2={a = 0x0, b = 0x0}) #2 0x00000000004004ef in main () (gdb) c Continuing. Breakpoint 1, 0x00000000004004fb in breakpt () (gdb) bt #0 0x00000000004004fb in breakpt () #1 0x000000000040053e in int_param_two_reg_pieces (operand0=0xdeadbe05, operand1=0xdeadbe0100000000, operand2=0x0) #2 0x00000000004004f5 in main () (gdb) quit ## END ## In both backtraces the values for operand0, operand1, and operand2 are wrong. In the first backtrace the correct values are: operand0={a = 0xdeadbe04deadbe05, b = } operand1={a = , b = 0xdeadbe00deadbe01} operand2= In the second backtrace the correct values are: operand0= operand1= operand2= In the second case we must mark the whole value as optimised out as the variable is an integer type, I can't imagine how we'd show a partially optimised out integer variable. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.