OS: Linux, Ubuntu 19.04, x86-64 Overview: Within gdb, print &variable showed different address from in program printf("%p", &variable). This was present when using gcc compile flags -gstabs and -gstabs+, but not when using -ggdb. Not sure if this bug is on the gcc side or on the gdb side. Steps to reproduce: This occurred working on the following library: https://github.com/DylanTomberlin/lldpd commit: 9fbae6d You may need to install autotools or other components to run the following: $ ./autogen.sh $ ./configure CFLAGS="-O0 -gstabs+" $ make clean check (there will be a failed test) $gdb check_lldp.c (gdb) break protocols/lldp.c:707 (gdb) n (gdb) n (prints out printf statement of &tlv_size) (gdb) print &tlv_size Actual Results: &tlv_size is listed by gdb as larger than by the compiled printf("%p", &tlv_size) by 0x10. tlv_size is an int, so this is 4 ints off. This is shown by (gdb) print &tlv_size not to change values when it is obviously changing. (gdb) print *(&tvl_size - 4) will print the same result as compiled printf("%p", &tlv_size). This bug was present when compiling with -gstabs+ and -gstabs, but not -ggdb. Expected results: gdb should not have an offset from the actual variable address.
$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.3.0-6ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)
Hi Dylan, Just wondering, is there any requirement for you to use stabs? GCC + GDB receive a lot more testing using the DWARF debug info format, so you will likely get better results. I don't doubt that there is a bug somewhere in the stabs implementation, and if so we would welcome a fix for it, but I am just wondering if there's something forcing you to use stabs.
Hi Simon, No, there wasn't a particular reason to use gstabs. I'm just an intern figuring it out as I go, so picked one off a list and the description made it sound like it was specialized to gdb. Planning on using ggdb moving forward, just figured I'd report it. Don't think I have time to find a fix myself. Thanks, Dylan
The gcc man page looks quite out of date, and therefore misleading. I don't know if -ggdb produces anything more useful than -g these days. In general, I would suggest using simply -g (equivalent to -g2) or -g3. -g3 produces information about macros, which -g doesn't produce, so it allows you to print and use macros in GDB. If you have: #define SUM(x, y) (x + y) you can use: (gdb) info macro SUM and: (gdb) print SUM(1, 3) $1 = 4
That's super helpful, thanks!
Moving to a different component.