Code: #include "stdint.h" int a, b; volatile int c; int16_t func_3(); int16_t func_3() { int64_t l_126[4] = {0x5C253C716A15F506LL, 0x5C253C716A15F506LL, 0x5C253C716A15F506LL, 0x5C253C716A15F506LL}; b = l_126[0]; return c; } int main() { func_3(); } Compile: $ clang -O1 -g r.c $ clang -v clang version 15.0.7 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg System configuration file directory: /etc/clang Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/11 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 GDB Behavior: (gdb) b func_3 Breakpoint 1 at 0x1130: func_3. (2 locations) (gdb) r Starting program: /home/john/documents/debugger-bugs/struct_syn/reduce/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, func_3 () at r.c:8 8 b = l_126[0]; (gdb) p l_126 $1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>} (gdb) info addr l_126 Symbol "l_126" is a complex DWARF expression: 0: DW_OP_constu 6639779683436459270 10: DW_OP_stack_value [8-byte piece].
check_pieced_synthetic_pointer looks fishy: if (p->location != DWARF_VALUE_IMPLICIT_POINTER) return false; Seems like it should require a positive match here.
I wrote a test case using the DWARF assembler but I get a different failure mode: (gdb) print noptr $1 = {6639779683436459270, 0, 0, 33} I think those last 3 values should be <optimized out>. Possibly the difference is that in my test, the variable is a global -- not sure though.
> [8-byte piece]. Aha, this means DW_OP_piece in that output -- I didn't realize. With this I can reproduce it.
I have a patch.
https://sourceware.org/pipermail/gdb-patches/2023-April/199003.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=245f9db1fa8a355e9b18d0966fe20d6341e36813 commit 245f9db1fa8a355e9b18d0966fe20d6341e36813 Author: Tom Tromey <tom@tromey.com> Date: Thu Apr 20 15:47:41 2023 -0600 Do not print <synthetic pointer> when piece is optimized out A user reported a bug where printing a certain array of integer types would result in the nonsensical: (gdb) p l_126 $1 = {6639779683436459270, <synthetic pointer>, <synthetic pointer>, <synthetic pointer>} I tracked this down to some issues in the DWARF expression code. First, check_pieced_synthetic_pointer did not account for the situation where a location expression does not describe all the bits of a value -- in this case it returned true, meaning there is a synthetic pointer, but in fact these bits are optimized out. (It turns out this incorrect output had already been erroneously tested for as well.) Next, rw_pieced_value did not mark these bits as optimized-out, either. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30296
Fixed.