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

Re: RFA: breakpoint.c and infrun.c changes


On Sep 23,  7:41pm, Stan Shebs wrote:

> A very nice piece of analysis!  I had to read through it about four
> times to understand it all, but the reasoning seems sound.  As we
> discussed on the phone, testing on a small assortment of relevant
> platforms is still worthwhile, just in case practice is trickier than
> theory. :-)

As I told you on the phone, I've tested on i386 linux and saw no
regressions.

I've tested with the d10v simulator and saw no regressions.

I tried to test the i960, but the i960 simulator did not work well for
me.  I'll try against an actual board if you think it's important. 
(After looking at the nightly testing results for this target, I have
doubts about being able to get it to work properly.  The one recent
test that did work properly had 1034 failures.  But most of the recent
and even not so recent tests show that the testsuite did not complete
successfully.)

I've tested on the alpha (running linux), but I'm not sure what to
make of the results.  On the one hand, I do see *fewer* failures after
I apply my patch.  But I've run the test suite a number of times and
get different results each time I run it.  The good thing is that
there aren't any new failures in the breakpoint or single step tests. 
(I ran my tests on the machine called `dot'.)

> I'd also like us to look into JimB's suggestion that the PC could be
> pre-adjusted according to DECR_PC_AFTER_BREAK before anything in
> execution control looks at it.  The analysis for that would involve
> looking at all the places where the PC is saved away, there are quite
> a few of them.

I'll make this a background task.

> In any case, assuming testing doesn't report any regression, I'd like
> to get this patch in soon so I can do my next phase of infrun
> simplification - there are just three more gotos left in
> handle_inferior_event, but so far I can't see how to evaporate them
> validly without breaking the function into a number of smaller pieces.

Okay.  Let me know what you want me to do about testing the i960. 
Also, I'd like Michael Snyder's blessing for the breakpoint.c changes.

> Also, it would be really great to add a testsuite case for temporary
> breakpoints and stepping that will always fail without your changes,
> and will pass otherwise, since it seems that there is currently no
> test to detect the failure you're fixing.

I'll construct such a test and have you take a look at it before
committing it.

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@cygnus.com

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