From: Jeff Dike <jdike@ka...> - 2002-10-28 23:11:29
> I discovered (as I'm sure than many have) that the optimizations that
> gcc performs causing debugging under gdb to be something of an
> adventure; the order of execution bounces around, and it's not easy
> to determine exactly when a variable's value is actually going to be
> How do others compile a UML kernel without optimization so
> that gdb use can be predictable?
Don't bother. Get used to it. It's not that bad.
> The functions that cannot be found at link time have one thing in
> common: They are declared (in one form or another) as "extern
> inline". (In some cases, they were "extern __inline" or "extern
> __inline__" .) These functions are scattered throughout the Linux
> code -- networking,
> drivers, and a few other places.
> I must confess that I find this declaration curious, as I don't know
> what it means for a function to be extern and inline at the same
> time. If someone can explain it to me, I would be happy to learn
> something new.
The gdb info docs explain this in some detail. extern inline makes the
function only inline - it is not available in its own right, iirc.
> Second, when I eliminate the "extern inline" functions by making them
> "static inline", I encounter an unexpected runtime problem.
> as the init process is coming up, I get a segmentation fault that
> cannot be handled, causing init to die.
Instead of moaning about it, why not provide some stack traces?
>===== Original Message From Jeff Dike <jdike@...> =====
>> How do others compile a UML kernel without optimization so
>> that gdb use can be predictable?
>Don't bother. Get used to it. It's not that bad.
It's not that it's so bad, it's that I'm surprised that it's difficult to make
it better. I figured that there might be a standard approach to doing so.
>The gdb info docs explain this in some detail.
Yes, a previous email pointed out the very same thing. I apologize for not
having checked the documentation sooner. That information helps a great deal.
That said, I still find it strange that changing those instances of "extern
inline" to "static inline" would compile but then cause changes in the
behavior at run-time. I'm using gcc 2.96 -- has anyone had bad experiences
with this verion? Is there another that I should try?
> [...] why not provide some stack traces?
Do you really want them, or are you wondering why I'm spending my time
persuing this approach? If the later, then I'd rather use UML as others do
under gdb and get back to the actul kernel changes that I was trying to test.
If the former, I will try to produce them and send them along. (On one
machine I think I can do that, as UML itself dies, but on another machine, it
locks the host kernel as well.)
From: Jeff Dike <jdike@ka...> - 2002-10-29 01:21:38
> It's not that it's so bad, it's that I'm surprised that it's difficult
> to make it better. I figured that there might be a standard approach
> to doing so.
There isn't really anything gdb can do about it. The instruction scheduler
intermingles instructions from different lines of code, so when gdb sees
an instruction belonging to a different line than it's currently on, that's
frequently one that's partially executed already.