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