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]

[RFC] Is skip_prologue_using_sal actually usable?


It defenitely has bugs; if the compiler only generates a single line
table entry for a function, it will skip the entire function.  That
can easily be fixed by the attached patch, but it seems we're really
confused with what skipping the prologue should actually do.  It seems
that in some instances we implement:

1. Skip instructions from the start of the function until we encounter
   the first instruction that doesn't belong to the prologue.

while in other cases we implement:

2. Skip instructions from the start of the function until we have seen
   all instructions belonging to the prologue.

Back in the old days, when prologues were fixed, 1 and 2 were pretty
much equivalent.  However, these days, with compilers migrating many
instructions into the prologue, the difference can be huge, and making
the wrong choice can be very annoying.

Core GDB code seems to use skipping the prologue for a single purpose:
determining the first line with "real code" of a function, to place a
breakpoint at that location or to determine where it should stop when
stepping into a function.  For this purpose I argue that we should
implement 1 instead of 2.  Implementing 2 means that we run the risk
of skipping interesting code.  If that code contains a branch, things
really break down because it means that GDB might never actually stop
in a function on which the user placed a breakpoint, or that GDB will
run until the program exits if you step into a function.

The drawback of implementation 1 is mainly that the prologue isn't
completely finished when GDB stops.  This means that GDB might not
print function arguments correctly because the stack frame hasn't been
fully setup yet.

The problem we're facing here's that our testsuite has many tests that
break down if we skip to little but almost none that break down if we
skip too much.  However, in real life, it's better to skip too little
than to much, as I argued above.

Things are complicated further by trying to skip the prologue by using
line number information.  Some compilers generate line number info for
the first instruction of a function, others don't.  In addition to
that, compilers generate buggy line number info.  It seems that
everytime GCC gains a new optimization that moves more stuff into the
prologue, the line number info generated for these instructions isn't
quite right.  As such, I think we should be very conservative when
skipping prologues solely using line number info, stopping at the line
containing the lowest address instead of the lowest line number as
skip_prologue_using_sal does.

Thoughts?

Mark


Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.141
diff -u -p -r1.141 symtab.c
--- symtab.c 22 Oct 2004 20:58:56 -0000 1.141
+++ symtab.c 7 Nov 2004 13:45:55 -0000
@@ -4050,6 +4050,11 @@ skip_prologue_using_sal (CORE_ADDR func_
 	  prologue_sal = sal;
 	}
     }
+
+  /* Avoid skipping the entire function.  */
+  if (prologue_sal.end >= end_pc)
+    return 0;
+
   return prologue_sal.end;
 }
 


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