stabs at function entry point?

Jim Ingham jingham@apple.com
Wed Mar 13 16:26:00 GMT 2002


Dale & Richard,

On Wednesday, March 13, 2002, at 01:58  PM, Dale Johannesen wrote:

>
> On Wednesday, March 13, 2002, at 01:11 PM, Richard Henderson wrote:
>
>> On Tue, Mar 12, 2002 at 05:32:37PM -0800, Dale Johannesen wrote:
>>> Our gdb guy, Jim Ingham, pointed out that gcc3 on Darwin (which uses
>>> dbx-style debug info [stabs]) is generating the first line-number
>>> stab in a function before the prologue.  Jim argues that it should
>>> be after the prologue, and has convinced Stan and me.
>>
>> Perhaps I'm mis-remembering, but I thought the first line number stab
>> goes with the very first instruction of the function, and the *second*
>> line number stab goes after the prologue.
>
> Yes, that is what happens now.  As a result, when you set a breakpoint
> on a function, gdb (ours, anyway) stops at the first insn rather than
> after the prologue, which means the parameters and stack traceback
> don't show correctly.  Are you implying this should be fixed in gdb?
> That was my first impression, but Jim convincingly argued otherwise.

The problem here is that we have to interpret what it means to put a 
breakpoint by source line on the lines of a function before the first 
line of executable code.  If we follow what gcc currently emits, then we 
interpret this to mean that the breakpoint goes on the beginning of the 
prologue.  When we discussed this on some of Apple's mailing list the 
common response was "what's a prologue, and why do I want to know about 
it".  The real answer is in most cases they don't...

So my contention was that no one who is doing source level debugging 
ever wants to break at the beginning of the prologue.  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.

When Dale and I first discussed this, he suggested that gdb just throw 
away the first source line stab for each function it encounters.  But if 
gdb has to throw it away each time to get the debugging experience 
right, then that seems a pretty strong argument in itself that the 
compiler should not be emitting them...

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



More information about the Gcc mailing list