This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug symtab/14604] New: Display of partially optimised outstructures flowing over multiple registers.
- From: "aburgess at broadcom dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 21 Sep 2012 16:27:57 +0000
- Subject: [Bug symtab/14604] New: Display of partially optimised outstructures flowing over multiple registers.
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14604
Bug #: 14604
Summary: Display of partially optimised out structures flowing
over multiple registers.
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: symtab
AssignedTo: unassigned@sourceware.org
ReportedBy: aburgess@broadcom.com
Classification: Unclassified
Created attachment 6644
--> http://sourceware.org/bugzilla/attachment.cgi?id=6644
x86-64 assembler test file for issue.
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 the DWARF location for a variable is a register, but the size of the
variable is greater than the size of the register then gdb will assume the
variable "flows" over into the next register.
The idea of what the next register is relies on the internal register
number of gdb, this is probably a bug. There are comments in the attached
test file describing this in more detail.
This flowing behaviour was added (back) to support the AVR target, see
http://sourceware.org/ml/gdb-patches/2011-10/msg00052.html
and maybe this behaviour should be made target specific, and this flowing
behaviour should be unsupported on other targets, the correct way to
locate a variable in multiple register is using DWARF piece information.
Anyway, given that gdb currently supports this "flowing" behaviour...
The test creates a call stack:
main --> struct_param_single_reg_loc --> breakpt
Where the function "struct_param_single_reg_loc" holds variables in
registers. The function "breakpt" marks some of these register as
optimised out. We then backtrace from breakpt and look at how gdb
displays the variables in "struct_param_single_reg_loc".
Having a variable in a register that is marked as optimised out by a later
frame should probably be fixed in the dwarf producer, it may not be worth
the effort to improve gdb in this case.
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) 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 0x000000000040051e in struct_param_single_reg_loc (
operand0=<optimized out>, operand1=<optimized out>,
operand2=<optimized out>)
#2 0x00000000004004e9 in main ()
(gdb) quit
In the backtrace notice that operand0, operand1, and operand2 are marked
as completely optimised out, in theory we could do better, something like
this:
#1 0x000000000040051e in struct_param_single_reg_loc (
operand0={a = 0xdeadbe00deadbe01, b = <optimized out>},
operand1={a = <optimized out>, b = 0xdeadbe04deadbe05},
operand2=<optimized out>)
--
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.