[Bug symtab/14604] New: Display of partially optimised out structures flowing over multiple registers.

["aburgess at broadcom dot com" <sourceware-bugzilla@sourceware.org>]

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.