This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stabs at function entry point?

On Wednesday, March 13, 2002, at 02:07  PM, Dale Johannesen wrote:

> On Wednesday, March 13, 2002, at 12:52 AM, Geoff Keating wrote:
>> Line number comments are also used for the reverse mapping: Given a
>> location, what source line corresponds to it?
>> So, suppose the user stops at the first instruction of a function.
>> What line should the debugger display?  Hopefully, some line in the
>> function.  Thus, there should be at least one line-number stab at the
>> very start of the function.
> Doesn't follow.  There is also a function stab, which contains the
> line number of the beginning of the function definition.  gdb does
> use that.  The behavior with my patch (but with the scheduler off)
> is as follows:
> When you breakpoint on a function:  gdb stops after the prologue,
> and displays the first line within the function that has executable
> code.
> When you breakpoint on *&function:  gdb stops at the first insn,
> and displays the line of the function definition.
> That looks OK to me; what do you think?

Right, the only odd thing that happens is that if you do

(gdb) info line *&function

the line number returned is actually the last line of the previous 
function.  While this is wrong, I don't think this is anywhere near as 
wrong as breaking on the line where the function is defined, and having 
it stop with the stack all wrong, etc...  If you are stopping in the 
prologue, you are probably NOT doing source line debugging, after all.  
So why would you really care exactly what line this is?

>> If the prologue is intermixed with the code for statements the
>> function, I'd like to think that we'd also get correct line numbers
>> for the statements, even though the prologue hasn't finished executing
>> yet.  Otherwise it's possible to have no way to set a breakpoint on
>> some lines even though there are instructions corresponding to those
>> lines.  In fact, if the epilogue is treated similarly, and the
>> prologue and epilogue overlap (theoretically possible), there might be
>> no line number notes at all.
> I have no strong feelings about what should happen when scheduling is
> on; debug info is unreliable in that case anyway.  What do you think, 
> jim?

In this case gcc (at least 2.95, I haven't checked this with 3.0) puts 
the second source-line stab on the first instruction it emits that is 
NOT from the prologue.  So as long as there are some non-prologue 
instructions in the function, there will be a place where you can break 
by line number.  I don't think that the problem you are worried about 
will actually occur.

Jim Ingham                         
Developer Tools - gdb
Apple Computer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]