This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] New GDB target iq2000
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;
}