https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534

--- Comment #38 from Lukas Grätz <lukas.gra...@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.


I see, this gives me:


(gdb) frame 4
#4  0x00000000004012aa in qux () at bar-artificial.c:55
55        baz (a, b, c, d, e, f, g, h);
(gdb) p a
$1 = 42
(gdb) p b
$2 = 43
(gdb) p c
$3 = 44
(gdb) p d
$4 = <optimised out>
(gdb) p e
$5 = <optimised out>
(gdb) p f
$6 = <optimised out>
(gdb) p g
$7 = <optimised out>
(gdb) p h
$8 = <optimised out>
(gdb) p $r12
$9 = <not saved>


I checked the dwarf:


$ llvm-dwarfdump bar-artificial-mod
[...]
0x0000009f:   DW_TAG_subprogram
                DW_AT_external  (true)
                DW_AT_name      ("qux")
                DW_AT_decl_line (42)
                DW_AT_prototyped        (true)
                DW_AT_low_pc    (0x00000000004011d2)
                DW_AT_high_pc   (0x00000000004012db)
                DW_AT_frame_base        (DW_OP_call_frame_cfa)
                DW_AT_call_all_calls    (true)
                DW_AT_sibling   (cu + 0x02f0)
[...]
0x000000ee:     DW_TAG_variable
                  DW_AT_name    ("d")
                  DW_AT_decl_line       (47)
                  DW_AT_decl_column     (0x07)
                  DW_AT_type    (cu + 0x0060 "int")
[...]
$ objdump -W bar-artificial-mod
[...]
 <2><ee>: Abbrev Number: 2 (DW_TAG_variable)
    <ef>   DW_AT_name        : d
    <f1>   DW_AT_decl_file   : 1
    <f1>   DW_AT_decl_line   : 47
    <f2>   DW_AT_decl_column : 7
    <f3>   DW_AT_type        : <0x60>
    <f7>   DW_AT_location    : 0x6e (location list)
    <fb>   DW_AT_GNU_locviews: 0x6a
[...]
Contents of the .debug_loclists section:
[...]
    0000006e v000000000000000 v000000000000000 views at 0000006a for:
             0000000000401216 000000000040121f (DW_OP_reg0 (rax))
    00000075 v000000000000000 v000000000000000 views at 0000006c for:
             000000000040121f 00000000004012d1 (DW_OP_reg3 (rbx))
    0000007c <End of list>
[...]


The problem is that we are not within the loclist range. So in principle, we
cannot get the value of the variable, the variable is just not visible. But
since gdb is very clever, it searched whether either the value of rax or rbx
from within the loclist range remained somewhere. And apparently, for the
version without the patch, the value of rbx was saved. For the optimized
version with the patch, rbx was not saved, so the value could not been
reconstructed.

In my opinion, it is just fancy that gdb can do that.


Coming back to the "simple.c" example:


$ objdump -W simple
[...]
 <2><ab>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <ac>   DW_AT_name        : (indirect string, offset: 0x85): argc
    <b0>   DW_AT_decl_file   : 1
    <b0>   DW_AT_decl_line   : 2
    <b0>   DW_AT_decl_column : 14
    <b1>   DW_AT_type        : <0x35>
    <b5>   DW_AT_location    : 0x10 (location list)
    <b9>   DW_AT_GNU_locviews: 0xc
[...]
Contents of the .debug_loclists section:
[...]
    00000010 v000000000000000 v000000000000000 views at 0000000c for:
             0000000000401126 000000000040112e (DW_OP_reg5 (rdi))
    00000015 v000000000000000 v000000000000000 views at 0000000e for:
             000000000040112e 000000000040112f (DW_OP_entry_value: (DW_OP_reg5
(rdi)); DW_OP_stack_value)
    0000001d <End of list>
[...]


And rdi was saved nowhere, regardless of the patch. So gdb could not
reconstruct the value of argc.

Reply via email to