Re: [RFA] New GDB target iq2000

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Mar 05, 2005 at 07:13:12PM +0100, Mark Kettenis wrote:
> 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.

This looks like an obvious fix to me.

>    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.

Yes.  I'm hoping to expand use of it, which will improve test coverage,
and Kevin has an analysis of another problem with it which should be
fixed.

>    >    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.

Could you explain why that particular property makes a difference?

I'm not talking about an ultra-specialized "simulator" the way that
current GDB prologue analyzers work; I'm talking about most of a
complete architecture simulator, with appropriate hooks to tell GDB
what it wants to know.  There's plenty of other ways we could use this
information.

Here's one I've been thinking about in particular: some instructions
are "safe" to simulate on a running process, though not all.  When a
breakpoint covers an instruction which is "safe", we can simulate the
instruction instead of having to remove the breakpoint and single-step. 
Huge win with threads.

> 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.

Just checking, but first-line breakpoints should go at the lower limit
and scanning until the upper limit - is that right?

-- 
Daniel Jacobowitz
CodeSourcery, LLC