gcc and gdb bug caused by imacros usage (gdb emits only <command-line>)
Heads up to those performing debugging on 3.x Recently when I was trying to perform symbolic debugging on components built from the 3.x tree I discovered I was unable to get any source file information in gdb, it would only emit <command-line> as the source filename and I could not get gdb to list source, show it in a backtrace, etc. Thanks to Nalin Dahyabhai who discovered the root cause, it's covered in this bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=1004526 Apparently using -imacros causes the failure. To be honest I wasn't all that familiar with -imacros myself. The workaround I came up with was to replace -imacros in Make.inc.in with -include. I don't know which version of the gcc/gdb tool chain this shows up in or if it's specific to how debuginfo packages are produced during the RPM build process. But if you do hit this issue you'll discover it's almost impossible to do any useful debugging, so heads up, HTH -- John
John Dennis wrote:
Recently when I was trying to perform symbolic debugging on components built from the 3.x tree I discovered I was unable to get any source file information in gdb, it would only emit <command-line> as the source filename and I could not get gdb to list source, show it in a backtrace, etc.
Thanks to Nalin Dahyabhai who discovered the root cause, it's covered in this bugzilla.
Which isn't visible to anyone, apparently.
Apparently using -imacros causes the failure. To be honest I wasn't all that familiar with -imacros myself. The workaround I came up with was to replace -imacros in Make.inc.in with -include.
That works for some platforms. IIRC, the -imacro was added for a reason.
I don't know which version of the gcc/gdb tool chain this shows up in or if it's specific to how debuginfo packages are produced during the RPM build process.
But if you do hit this issue you'll discover it's almost impossible to do any useful debugging, so heads up, HTH
I'm inclined to ignore it for the short term. I don't see it on any platforms I use, and the upstream gcc / gdb really should be fixed to work as advertised. Alan DeKok.
On 01/18/2014 04:01 PM, Alan DeKok wrote:
John Dennis wrote:
Recently when I was trying to perform symbolic debugging on components built from the 3.x tree I discovered I was unable to get any source file information in gdb, it would only emit <command-line> as the source filename and I could not get gdb to list source, show it in a backtrace, etc.
Thanks to Nalin Dahyabhai who discovered the root cause, it's covered in this bugzilla.
Which isn't visible to anyone, apparently.
My apologizes.
Apparently using -imacros causes the failure. To be honest I wasn't all that familiar with -imacros myself. The workaround I came up with was to replace -imacros in Make.inc.in with -include.
That works for some platforms. IIRC, the -imacro was added for a reason.
I don't know which version of the gcc/gdb tool chain this shows up in or if it's specific to how debuginfo packages are produced during the RPM build process.
But if you do hit this issue you'll discover it's almost impossible to do any useful debugging, so heads up, HTH
I'm inclined to ignore it for the short term. I don't see it on any platforms I use, and the upstream gcc / gdb really should be fixed to work as advertised.
Yup, I wasn't suggesting it be changed upstream, it affects only a subset of platforms. Rather it was a friendly bit of shared information just in case someone does hit it. I had not a clue why gdb couldn't do source level debugging and googling the issue didn't turn up any hints. And yes, it's really a gcc/gdb issue. -- John
On 18 Jan 2014, at 21:52, John Dennis <jdennis@redhat.com> wrote:
On 01/18/2014 04:01 PM, Alan DeKok wrote:
John Dennis wrote:
Recently when I was trying to perform symbolic debugging on components built from the 3.x tree I discovered I was unable to get any source file information in gdb, it would only emit <command-line> as the source filename and I could not get gdb to list source, show it in a backtrace, etc.
Thanks to Nalin Dahyabhai who discovered the root cause, it's covered in this bugzilla.
Which isn't visible to anyone, apparently.
My apologizes.
"You are not authorized to access bug #1004526."
Apparently using -imacros causes the failure. To be honest I wasn't all that familiar with -imacros myself. The workaround I came up with was to replace -imacros in Make.inc.in with -include.
That works for some platforms. IIRC, the -imacro was added for a reason.
Yes, it allows us to include temporary macro definitions from the autoconf generated header files. -include should work ok, but -imacro is more appropriate. Using -imacro/-include allows us to include generated header files during build time, without having an #include <> line for them in any files. This means we don't have to install the autoconf generated headers in order for the FreeRADIUS headers to work. Installing the autoconf generated headers is bad, because it can cause conflicts for other projects using autoconf that wish to build against the FreeRADIUS headers.
I don't know which version of the gcc/gdb tool chain this shows up in or if it's specific to how debuginfo packages are produced during the RPM build process.
But if you do hit this issue you'll discover it's almost impossible to do any useful debugging, so heads up, HTH
I'm inclined to ignore it for the short term. I don't see it on any platforms I use, and the upstream gcc / gdb really should be fixed to work as advertised.
Yup, I wasn't suggesting it be changed upstream, it affects only a subset of platforms. Rather it was a friendly bit of shared information just in case someone does hit it. I had not a clue why gdb couldn't do source level debugging and googling the issue didn't turn up any hints. And yes, it's really a gcc/gdb issue.
Another good reason to switch to clang/lldb. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi,
I'm inclined to ignore it for the short term. I don't see it on any platforms I use, and the upstream gcc / gdb really should be fixed to work as advertised.
I hit it last time I tried to debug something, short before 3.0.1. This was a stock openSUSE 13.1 64-Bit install. Maybe the platforms where this occurs aren't that exotic, which would be bad for incoming bug reports. I'm attaching version information from the box that did it. Stefan # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) # gdb --version GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux".
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Stefan Winter