This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB 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: problem debugging assembler functions


On Tue, Jun 14, 2005 at 06:54:03PM +0400, Vladimir Prus wrote:
> > > 2. In my case, no function names for assembler modules are present in
> > > debug info, but line information is there, so the function is debuggable.
> > > Is there a way to check of line info in condition, not for function name?
> >
> > You have line numbers, but not even minimal symbols?  That is, ELF
> > symbols, not DWARF2 symbols.  
> 
> Exactly. ELF symbol table is absolutely empty. 
> 
> > That's really bizarre.  
> 
> Well, for a binary for embedded system with no dynamic linking this is not so
> unreasonable. Anyway, that's not something I can easily change.

Not having dynamic symbols, sure, that's perfectly reasonable.  Those
go into target memory.  But this is far from the only thing in GDB that
is not going to work without a static symbol table!  For instance, you
can't use prologue analysis.  You'll never find the start of any
function.

> > We don't have a  
> > good interface for handling functions with line numbers but no sym or
> > minsym, but perhaps we need one.  I agree that the presence of line
> > number information seems more relevant right here.
> 
> FWIW, I've just modified that code to be:
> 
>   ecs->sal = find_pc_line (stop_pc, 0);
>   .......
>   if (step_over_calls == STEP_OVER_UNDEBUGGABLE
>       && ecs->sal.line == 0)
> 
> and it works as expected. Does the change seem reasonable?

I'm not thrilled with adding another lookup here; this code executes
quite a few times when stepping.  It does seem plausible, but it would
need wider testing.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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