stabs at function entry point?

[Jim Ingham]

Hi, all...
On Wednesday, March 13, 2002, at 06:28  PM, Dale Johannesen wrote:

>
> On Wednesday, March 13, 2002, at 06:18 PM, Richard Henderson wrote:
>
>> On Wed, Mar 13, 2002 at 04:25:48PM -0800, Jim Ingham wrote:
>>> So my contention was that no one who is doing source level debugging
>>> ever wants to break at the beginning of the prologue.
>>
>> Which is patently false.  I do.  All the time.  It's almost
>> impossible to avoid it when trying to debug optimized code.
>>
>>> All sorts of oddities happen then (the stack is wrong, the current
>>> frame is wrong, etc) which from a source debugging point of view
>>> are hard to understand.
>>
>> Yes indeed they are (though it would be greatly helped by using
>> dwarf2 frame unwind info and location lists).  Nevertheless, if
>> you've got optimized code, gdb's notion of what constitutes a
>> prologue is worthless anyway.  So instead of "b foo; cond x == 1234"
>> you have to do "b *foo; cond $a0 == 1234".
>
> Yes, I do this too.  Which means I don't care what "b foo" does in
> optimized code.  Indeed, I've found the debugging info put out with
> optimization to be more confusing than helpful; to get anything done
> I wind up debugging at assembly level anyway.
>
> But the main point of the change was to get better behavior in
> *unoptimized* code.  I suppose this point wasn't made very well
> before.
>

Right, sorry about that.

The debugging model that most people use is to build unoptimized, and do 
as much testing there as possible.  Then if you get a bug, you first try 
it against the unoptimized build.  If it occurs there as well, you go 
"Whew..." and dig in.  For this kind of debugging, you are assuming that 
it is a real bug in your code, not some subtle interaction with the 
compiler (or compiler bug).  And for this case, you don't want to know 
about compiler constructs like the prologue.

 From my experience, the vast majority of the App developers out there 
are really only happy in this mode of development, so getting this right 
is pretty important...

However, when you have a bug that only shows up in the optimized version 
of the code, you are going to have to read assembly code to sort it 
out.  In this case, as Dale points out, the source line info is really 
not all that helpful - but the bug is almost certainly not going to be 
detectable from the source line info anyway.

I want to make the source debugging behavior as good as possible in the 
case where it is really useful.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer