This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: mi*-watch.exp: Test both hardware and software watchpoints
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