https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93888
Bug ID: 93888
Summary: Incorrect DW_AT_location generated for
copy-constructed function argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mgulick at mathworks dot com
Target Milestone: ---
Created attachment 47889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47889&action=edit
reproducer code, gdb test script, makefile and README
Hi,
I have observed that gcc produces an incorrect DW_AT_location list for a
function argument when both of the following are true:
a) The argument is passed by value with the help of a copy constructor
b) The function is inlined
When this occurs, the DW_AT_location list actually ends up pointing to the
address of the data, not the data itself. Thus, it is either missing a
DW_OP_deref, or contains a gratuitous DW_OP_stack_value.
I have turned off all other optimizations and the issue is still reproducible.
I have observed this issue on all versions of GCC I have available to test,
including the current git master, 8.3, 6.3, 4.9, 4.7, and 4.4.
Here is a sample program:
class K
{
public:
K() {}
// Commenting out this copy-constructor makes the test pass
K ( K const& rhs ) {
m_storage[0] = 'C'; // 0x43
}
// Initialize this array to some known values (0x42)
char m_storage[ 8 ] = {'B','B','B','B','B','B','B','B'};
};
// Not inlining also fixes the issue
__attribute__((always_inline))
bool func1(const K func1_k) {
return func1_k.m_storage[0] == 'C';
}
int main() {
K my_k;
return func1(my_k);
}
I am compiling this with 'g++ -g -O0 -fvar-tracking ...'.
In gdb, if I break inside 'func1' and print the value of 'func1_k', the wrong
value is printed. If I instead print '*(K*)func1_k', I get the expected value.
If I ask gdb what the address of func1_k is, I get:
(gdb) info address func1_k
Symbol "func1_k" is multi-location:
Range 0x40113f-0x401148: a complex DWARF expression:
0: DW_OP_breg6 -8 [$rbp]
2: DW_OP_stack_value
I verified with dwarfdump that this matches the value in the .o file, so it
does not appear to be a gdb bug. I am using the latest gdb 9.1 release.
I have attached a tarball containing the reproduction code, along with a gdb
test script, and a README with additional details.
While this issue itself is relatively minor, there isn't an easy workaround if
you need to debug optimized code. Also, in the production code where this
issue was found, the value being passed happens to be a boost::optional which
we have a gdb pretty-printer setup for, and this causes the unfortunate
side-effect that running a 'backtrace' command in gdb any time this function is
in the stack (which is pretty much all the time) causes the boost
pretty-printer to try to dereference an invalid value, and gdb segfaults.
I spent some time trying to debug gcc itself, but I got lost very quickly and
was unable to localize where the issue is. Hopefully this reproduction case is
small-enough to help you determine the source of the error.
Thank you!
-Mike
