Re: problem debugging assembler functions

[Vladimir Prus <ghost@cs.msu.su>]

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