Re: [RFC/RFA/sparc] problem with prologue analyzer

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Fri, 26 Nov 2004 14:34:10 -0800
   From: Joel Brobecker <brobecker@adacore.com>

      Breakpoint 2, 0x00010aac in marker2 (a=720) at break1.c:41
      41      int marker2 (a) int a; { return (1); }  /* set breakpoint 9 here */
      (gdb) FAIL: gdb.base/break.exp: run until quoted breakpoint

Hmm, the test PASSes for me on sparc-sun-solaris2.9 with GCC 3.2.3,
which generates essentially the same prologue code.

   This test used to pass with 5.3. Doing a bit of archeology, I discovered
   that the code analyzing problogues has been heavily rewritten at the end
   of 2003, and that the piece of code that handles these store insns got
   lost during one large code rewrite.

I left that bit of code out quite deliberately.  The idea was to
implement the minimum of prologue analysis code necessary to get the
frame unwinder working, and rely on debugging information for skipping
prologues (which the old code didn't do).  It appears that your
compiler isn't generating the proper debug info, or GDB isn't handling
that debug info properly.

Now if indeed GCC is generating bad debug info, and we accept that, it
makes sense to improve the prologue analyzer where it makes sense.  We
must realize that we probably will never get it completely right.  We
must also realize that there's a rather fundamental question here:
Should we be conservative with prologue skipping, risking the "wrong
arguments" problem you're seeing, or should we skip any code that is
likely to belong to the prologue, risking stopping after real code has
been executed.

Ultimately the "wrong arguments" case is a problem with incomplete
debug info, which might go away when GDB implements proper "multiple
location" support.  So I'm in favour of being a bit conservative here.

That said, I'm not against improving the prologue analyzer here.
However, as the comment that goes with the code that your patch buts
back in says, there are some problems with that code.  I think code
needs some polishing, splitting out the 32-bit and 64-bit cases.  I'll
try to come up with a somewhat better patch.

Mark