This is an archive of the discontinued LLVM Phabricator instance.

[MIPS] Fix TestCrashDuringStep.py for MIPS
ClosedPublic

Authored by jaydeep on Dec 3 2015, 3:52 AM.

Details

Reviewers
clayborg
labath
Summary

Single stepping requires setting software breakpoint at address 0x0. This results in input/output error instead of SIGSEGV. Using “continue” instead of single stepping avoids setting of software breakpoint at address 0x0.

Diff Detail

Repository
rL LLVM

Event Timeline

jaydeep updated this revision to Diff 41734.Dec 3 2015, 3:52 AM
jaydeep retitled this revision from to [MIPS] Fix TestCrashDuringStep.py for MIPS.
jaydeep updated this object.
jaydeep added a reviewer: clayborg.
jaydeep set the repository for this revision to rL LLVM.
jaydeep added subscribers: bhushan, slthakur, mohit.bhakkad and 2 others.
labath added a subscriber: labath.Dec 3 2015, 4:16 AM

I believe this defeats the purpose of the whole test, which (I think) is to check that crashes during the actual "step" operation are handled correctly. We already have other tests which test crashing after a "continue" so I don't think this adds any value. A better course of action in my opinion would be to xfail or skip this test.

It will be tricky, but I think the proper way to make these kinds of things work with software single stepping is to detect (during the instruction emulation phase) that the instruction will crash (because it jumps to unmapped memory, for instance). Then you can omit putting the breakpoint and just issue the "continue" command normally, and the process will stop anyway because of the signal. This way the higher levels of the debugger (and the user) can be oblivious to the fact that software single stepping is in use, and everything will work normally.

But if having this working is not important for you, then I suggest you just go with XFAIL.

jaydeep updated this revision to Diff 41840.Dec 3 2015, 10:16 PM

Marked as XFAIL

labath accepted this revision.Dec 4 2015, 1:43 AM
labath added a reviewer: labath.

Thanks.
If you wish, you can link it to the same bug as the arm xfail above, as that is the same underlying issue.

This revision is now accepted and ready to land.Dec 4 2015, 1:43 AM