Re: [RFA] New GDB target iq2000

[Mark Kettenis <kettenis@gnu.org>]

   Date: Sat, 5 Mar 2005 11:44:52 -0500
   From: Daniel Jacobowitz <drow@false.org>

   On Sat, Mar 05, 2005 at 12:28:53PM +0100, Mark Kettenis wrote:
   >    Date: Fri, 4 Mar 2005 17:01:04 -0500
   >    From: Daniel Jacobowitz <drow@false.org>
   > 
   >    I left the other function alone.  skip_prologue_using_sal is already a
   >    bit bogus, for the reasons identified by Kevin as well as for at least
   >    one other that I can see.  find_last_line_symbol is even boguser. 
   >    Basically, any code that compares the LINE member of two arbitrary SALs
   >    _must_ be wrong.  They don't even need to be in the same source file.
   > 
   > Another issue with skip_prologue_using_sal() is that it will happily
   > skip the entire function if the function body is basically empty.  I
   > really think it should be deprecated, and shouldn't be used in any new
   > code.

   Hum... so it will.  I rather think it should be fixed.  I have a patch
   to fix the most common occurance of that, when the line notes look
   like:
	   line1:
	   line2:
		   ret

   For a compiler which doesn't use the two line note convention, of
   course, it's bogus - but so is lots of the rest of GDB.

That's not an excuse for not trying to come up with an algorithm
that's more robust.  Attached is the patch that I have sitting in my
tree.

   Could you explain why you think it should be deprecated?  Bear in mind
   that it's _new_ - it was derived from various similar things in tdep
   files, in an attempt to commonize.

And it was never properly tested.  And there was never a coordinated
attempt to use this common code.

   >    There's two things that GDB uses the guessed prologue line information
   >    for.  One is to place an initial breakpoint, so that the arguments have
   >    been saved.  This problem will hopefully eventually go away, with
   >    improved GCC -fvar-tracking - we should be able to print the arguments
   >    from anywhere.  Someone needs to spend a little love on the compiler
   >    side of this.
   > 
   > The important thing about placing the initial breakpoint, is that it
   > shouldn't be placed too far into the function.  In particular it
   > should not end up after a branch instruction.

   Yes.  I mentioned to Kevin off-list that I've been thinking about an
   ideal paradigm for implementing both this and prologue scanners.  What
   we need is a common simulator architecture which can "describe" the
   effects of instructions - enough instructions to handle prologues, at
   least.  A huge project for someday :-)

That suggestion has been made more than once in the past; I don't
really consider this viable for architectures where instructions
aren't fixed length.

Anyway, I think most problems are caused because we are trying to use
the same code for two distinct cases: (a) getting an upper limit for
the prologue end and (b) getting a lower limit for the prologue end.
Combining (a) and (b) results in having to determine the end of the
prologue exactly, which is much harder.

Mark


Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.144
diff -u -p -r1.144 symtab.c
--- symtab.c 15 Feb 2005 15:49:21 -0000 1.144
+++ symtab.c 5 Mar 2005 18:12:51 -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;
 }
 \f