Re: mi*-watch.exp: Test both hardware and software watchpoints

[Daniel Jacobowitz <drow@false.org>]

On Fri, Sep 14, 2007 at 04:28:36PM +0100, Maciej W. Rozycki wrote:
>  Well, I would have thought the destruction of the frame pointer marks the 
> beginning of the epilogue.  Though I can imagine an ABI relaxed enough to 
> let the compiler shuffle instructions around while optimising so that some 
> belonging to the body of a function actually arrive past the boundary.

Yes, some ABIs are so relaxed.  You can't migrate things past moving
the stack pointer (interrupts, signals) but the frame pointer is just
a convention on a lot of platforms.

> 
> > I don't intend to fix it right now, anyway.  And I really do not like
> > leaving failing tests.  Every few years, I try to reduce the failures
> > for a couple of platforms to zero.  I'm going to do it again after I
> > finish with multi-threaded watchpoints (next week hopefully; patches
> > coming this weekend).
> 
>  I guess they could act as incentive for platform maintainers. ;-)
> 
> > I think the right fix is going to have to involve GCC.  It should emit
> > correct unwind info for the epilogue; even without also adding the
> > epilogue markers to the line table, correct unwind info will solve
> > this problem 99% of the time.
> 
>  Fair enough.
> 
> > > +    set old_prefix $pf_prefix
> > > +    set pf_prefix "$pf_prefix $type: "
> > 
> > Is there a double space here?  IIUC pf_prefix will be something like
> > "gdb.mi/mi-watch.exp: ".
> 
>  I would have thought so as well, but the sequence above actually places a 
> single space character between the variables.  Perhaps it is another TCL 
> feature -- I am not sure if I can be bothered to get to the bottom of it 
> -- should I?

How about a double space after "$type: " in the output?  I bet there
is:

    if {[info exists pf_prefix]} {
        set message [concat $pf_prefix " " $message]
    }

(from dejagnu/framework.exp).

>  It is not completely bullet-proof, like the whole set of changes anyway, 
> as for platforms that do not support hw watchpoints at all the tests are 
> run twice using sw watchpoints and do FAIL for the variation assumed to be 
> hw.  It is not a regression though and a small waste of time only.  I can 
> see whether determining if hw watchpoints are truly available is doable at 
> some point, but I cannot promise any timeline at the moment.

It's quite hard to do.  I recommend the use of board files :-)

>  OK for this bit?

Yes, thanks again.

-- 
Daniel Jacobowitz
CodeSourcery