problem debugging assembler functions

problem debugging assembler functions

[Vladimir Prus]

Hello,
I'm trying to port gdb to a new architecture (with it's own compiler), and
run into problems with assembler functions. I can successfully step into
an assembler function, but when I run "step", instead of moving to the 
next instruction, gdb sets breakpoint at return address and continues.
Looking at the code, I see this (in infrun.c)

Line 2285:

 if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id))
 {
     ......
 }

Line 2428:

 if (step_over_calls == STEP_OVER_UNDEBUGGABLE
      && ecs->stop_func_name == NULL)
  {
       /* The inferior just stepped into, or returned to, an
         undebuggable function (where there is no symbol, not even a
         minimal symbol, corresponding to the address where the
         inferior stopped). 
        */

        ........

        insert_step_resume_breakpoint_at_frame (
             get_prev_frame (get_current_frame ()));  
  }


The condition is the second code block is taken and breakpoint is indeed
set. I have two questions:

1. Is "just stepped into ... function" comment accurate? I think that all
cases of steppin into function are handled by the previous

 if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) {}

condition, and all code paths inside that condition end with return. So, the
second code block is not executed when we've just stepped into a function.
Is the code intended to handle only the case when we've *returned* to
undebuggable function?

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?

Thanks in advance,
Volodya

Re: problem debugging assembler functions

[Daniel Jacobowitz]

On Tue, Jun 14, 2005 at 01:21:53PM +0400, Vladimir Prus wrote:
> Line 2285:
> 
>  if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id))
>  {
>      ......
>  }

FYI, this bit...

> Line 2428:
> 
>  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
>       && ecs->stop_func_name == NULL)
>   {
>        /* The inferior just stepped into, or returned to, an
>          undebuggable function (where there is no symbol, not even a
>          minimal symbol, corresponding to the address where the
>          inferior stopped). 
>         */
> 
>         ........
> 
>         insert_step_resume_breakpoint_at_frame (
>              get_prev_frame (get_current_frame ()));  
>   }

is somewhat newer than this bit.

> The condition is the second code block is taken and breakpoint is indeed
> set. I have two questions:
> 
> 1. Is "just stepped into ... function" comment accurate? I think that all
> cases of steppin into function are handled by the previous
> 
>  if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) {}
> 
> condition, and all code paths inside that condition end with return. So, the
> second code block is not executed when we've just stepped into a function.
> Is the code intended to handle only the case when we've *returned* to
> undebuggable function?

It was intended to handle both.  Nowadays, there's a good chance it has
handled only the latter.

> 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.  That's really bizarre.  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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: problem debugging assembler functions

[Vladimir Prus]

On Tuesday 14 June 2005 18:36, Daniel Jacobowitz wrote:
> On Tue, Jun 14, 2005 at 01:21:53PM +0400, Vladimir Prus wrote:
> > Line 2285:
> >
> >  if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id))
> >  {
> >      ......
> >  }
>
> FYI, this bit...
>
> > Line 2428:
> >
> >  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
> >       && ecs->stop_func_name == NULL)
> >   {
> >        /* The inferior just stepped into, or returned to, an
> >          undebuggable function (where there is no symbol, not even a
> >          minimal symbol, corresponding to the address where the
> >          inferior stopped).
> >         */
> >
> >         ........
> >
> >         insert_step_resume_breakpoint_at_frame (
> >              get_prev_frame (get_current_frame ()));
> >   }
>
> is somewhat newer than this bit.
>
> > The condition is the second code block is taken and breakpoint is indeed
> > set. I have two questions:
> >
> > 1. Is "just stepped into ... function" comment accurate? I think that all
> > cases of steppin into function are handled by the previous
> >
> >  if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id))
> > {}
> >
> > condition, and all code paths inside that condition end with return. So,
> > the second code block is not executed when we've just stepped into a
> > function. Is the code intended to handle only the case when we've
> > *returned* to undebuggable function?
>
> It was intended to handle both.  Nowadays, there's a good chance it has
> handled only the latter.

Ok.

> > 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.

> 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?

- Volodya

Re: problem debugging assembler functions

[Daniel Jacobowitz]

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

Re: problem debugging assembler functions

[Vladimir Prus]

On Tuesday 14 June 2005 18:58, Daniel Jacobowitz wrote:
> 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.

Do you mean prologue analysis for assembler modules? For C++ modules DWARF2 
info contains everything. 

Well, I don't need to analyse prologue for assembler modules at all, because
if I understand correctly it's only needed to proper unwind stack, and I have 
a much better way for stack unwinding. My target is actually a simulator, so 
I just store register values on each call instruction and can fetch them via
extended version of "get registers" remote protocol command.

> > > 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.  

The current code looks like:
 
  if (step_over_calls == STEP_OVER_UNDEBUGGABLE
      &&  ecs->stop_func_name == NULL
  {
  }

  if (step_range_end == 1)
  {
      /* It is stepi or nexti.
	  ...
      return;
  }

  ecs->sal = find_pc_line(stop_pc, 0)


So, moving 'find_pc_line' above will reasult in extra lookup only if 
- the command is stepi/nexti, or
- the first condition evaluates to true (which means we've entered   
  undebuggable code)

I have no idea is that's bad or not performance-wise, just clarifying what's
going on.
   
> It does seem plausible, but it would 
> need wider testing.

Ok.

- Volodya

Re: problem debugging assembler functions

[Daniel Jacobowitz]

On Tue, Jun 14, 2005 at 07:19:21PM +0400, Vladimir Prus wrote:
> Do you mean prologue analysis for assembler modules? For C++ modules DWARF2 
> info contains everything. 
> 
> Well, I don't need to analyse prologue for assembler modules at all, because
> if I understand correctly it's only needed to proper unwind stack, and I have 
> a much better way for stack unwinding. My target is actually a simulator, so 
> I just store register values on each call instruction and can fetch them via
> extended version of "get registers" remote protocol command.

It was an example of something which will go wrong without any symbols;
this is an assumption in GDB.  I bet you'll encounter it again
elsewhere.

> So, moving 'find_pc_line' above will reasult in extra lookup only if 
> - the command is stepi/nexti, or
> - the first condition evaluates to true (which means we've entered   
>   undebuggable code)
> 
> I have no idea is that's bad or not performance-wise, just clarifying what's
> going on.

Hmm, that's encouraging!  This might be a good improvement, then.

> > It does seem plausible, but it would 
> > need wider testing.
> 
> Ok.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: problem debugging assembler functions

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Tuesday 14 June 2005 19:27, Daniel Jacobowitz wrote:

> > So, moving 'find_pc_line' above will reasult in extra lookup only if
> > - the command is stepi/nexti, or
> > - the first condition evaluates to true (which means we've entered
> >   undebuggable code)
> >
> > I have no idea is that's bad or not performance-wise, just clarifying
> > what's going on.
>
> Hmm, that's encouraging!  This might be a good improvement, then.

So, is this change going in?

I attach the patch I'm using locally for your reference.

Thanks,
Volodya

[-- Attachment #2: debug_assembler_functions.diff --]
[-- Type: text/x-diff, Size: 933 bytes --]

Index: gdb/infrun.c
===================================================================
--- gdb/infrun.c	(revision 1678)
+++ gdb/infrun.c	(revision 1679)
@@ -2420,11 +2420,12 @@
 	}
     }
 
+  ecs->sal = find_pc_line (stop_pc, 0);
   /* NOTE: tausq/2004-05-24: This if block used to be done before all
      the trampoline processing logic, however, there are some trampolines 
      that have no names, so we should do trampoline handling first.  */
   if (step_over_calls == STEP_OVER_UNDEBUGGABLE
-      && ecs->stop_func_name == NULL)
+      && ecs->sal.line == 0)
     {
       /* The inferior just stepped into, or returned to, an
          undebuggable function (where there is no symbol, not even a
@@ -2461,9 +2462,7 @@
       stop_stepping (ecs);
       return;
     }
-
-  ecs->sal = find_pc_line (stop_pc, 0);
-
+      
   if (ecs->sal.line == 0)
     {
       /* We have no line number information.  That means to stop

Re: problem debugging assembler functions

[Vladimir Prus]

On Thursday 14 July 2005 17:45, Daniel Jacobowitz wrote:
> On Thu, Jul 14, 2005 at 12:54:41PM +0400, Vladimir Prus wrote:
> > On Tuesday 14 June 2005 19:27, Daniel Jacobowitz wrote:
> > > > So, moving 'find_pc_line' above will reasult in extra lookup only if
> > > > - the command is stepi/nexti, or
> > > > - the first condition evaluates to true (which means we've entered
> > > >   undebuggable code)
> > > >
> > > > I have no idea is that's bad or not performance-wise, just clarifying
> > > > what's going on.
> > >
> > > Hmm, that's encouraging!  This might be a good improvement, then.
> >
> > So, is this change going in?
> >
> > I attach the patch I'm using locally for your reference.
>
> Generally nothing goes in without a patch being submitted (with
> changelog, to gdb-patches). 

Okay, I'll post the patch there.

> It sounds like you're doing a lot of work 
> on GDB; have you considered getting a copyright assignment on file?

Am I required to do so? The two patches I've sent so far are fairly trivial.

Thanks,
Volodya

Re: problem debugging assembler functions

[Daniel Jacobowitz]

On Thu, Jul 14, 2005 at 12:54:41PM +0400, Vladimir Prus wrote:
> On Tuesday 14 June 2005 19:27, Daniel Jacobowitz wrote:
> 
> > > So, moving 'find_pc_line' above will reasult in extra lookup only if
> > > - the command is stepi/nexti, or
> > > - the first condition evaluates to true (which means we've entered
> > >   undebuggable code)
> > >
> > > I have no idea is that's bad or not performance-wise, just clarifying
> > > what's going on.
> >
> > Hmm, that's encouraging!  This might be a good improvement, then.
> 
> So, is this change going in?
> 
> I attach the patch I'm using locally for your reference.

Generally nothing goes in without a patch being submitted (with
changelog, to gdb-patches).  It sounds like you're doing a lot of work
on GDB; have you considered getting a copyright assignment on file?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: problem debugging assembler functions

[Daniel Jacobowitz]

On Thu, Jul 14, 2005 at 06:08:09PM +0400, Vladimir Prus wrote:
> > Generally nothing goes in without a patch being submitted (with
> > changelog, to gdb-patches). 
> 
> Okay, I'll post the patch there.

Thanks.

> > It sounds like you're doing a lot of work 
> > on GDB; have you considered getting a copyright assignment on file?
> 
> Am I required to do so? The two patches I've sent so far are fairly trivial.

These two probably don't need it; it was a suggestion for any future
work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC