This is the mail archive of the gdb-patches@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]

Re: [RFA] New GDB target iq2000


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.

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.

>    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 :-)

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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