This is an archive of the discontinued LLVM Phabricator instance.

Bug 24733: TestRegisters.py for Clang inferiors
ClosedPublic

Authored by abhishek.aggarwal on Sep 7 2015, 7:16 AM.

Details

Reviewers
labath
Summary
  • Bug 24457 can now be tested for inferiors compiled by clang compiler also.
  • Clang and GCC produces different assembly for the same inferior. Hence, Clang case has been handled separately.

Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>

Diff Detail

Event Timeline

abhishek.aggarwal retitled this revision from to Bug 24733: TestRegisters.py for Clang inferiors.
abhishek.aggarwal updated this object.
labath added inline comments.
test/functionalities/register/TestRegisters.py
193

First I would like to applaud for writing a test case for such a delicate issue. I know it's not easy given the current test infrastructure.

However, this change seems very fragile and likely to break due to random changes in clang implementation and/or command line flags. Even the gcc path can break if the gcc happens to produce slightly different output. I would like to avoid relying on hardcoded instruction counts.

How about we try something like this:

  • in the inline assembly, we prepend the code you want to test with "int3"
  • run the inferior normally. it should hit the debugger trap and stop (you can verify that the stop reason is indeed sigtrap)
  • the next instruction should point precisely at the code you want to test, without relying on any debug info or instruction counts
  • proceed with the test normally

what do you think?

test/functionalities/register/TestRegisters.py
193

Thanks for suggesting a nice way to fix it. I agree with you. I will make the changes.

Clang/GCC generate different assembly for same inferior.

Changed a.cpp to remove dependency of TestRegisters.py on assembly
instructions generated by Clang/GCC.

Changed TestRegisters.py to write a generic test vector for testing
Bug 24457.

labath accepted this revision.Sep 7 2015, 9:03 AM
labath edited edge metadata.

looks good. please also close the relevant bug after submission.

This revision is now accepted and ready to land.Sep 7 2015, 9:03 AM

Couldn't land this patch by arc due to merge conflicts. Hence merging it manually and closing this revision.

ovyalov added a subscriber: ovyalov.Sep 8 2015, 3:45 PM

I reverted the CL because it was causing TestRegisters.test_fp_special_purpose_register_read to fail on OSX:

  • stop reason = EXC_BREAKPOINT
  • "register read ftag" yields 0x80 instead of expected 0x8000

I reverted the CL because it was causing TestRegisters.test_fp_special_purpose_register_read to fail on OSX:

  • stop reason = EXC_BREAKPOINT
  • "register read ftag" yields 0x80 instead of expected 0x8000

Hi Oleksiy

Thanks for pointing out. Two things:

  1. Is it possible for you to share the failure log for this test on MacOSX? The expected value of ftag is 0x0080 and not 0x8000. Which compiler was used to compile inferior?
  2. Do you think that this patch needs reversion? In my opinion, this patch provides a much better (genric) way to test X87 FPU on Linux OS (atleast). I don't know whether the status for MacOSX would have even changed after you reverted this patch. I believe, it should still fail for MacOSX. I can take a look for MacOSX once you provide me failure logs. I would recommend to keep this patch and for the time being skip it for MacOSX. Once I find a fix for it on MacOSX, we can enable it for the same as well. What do you think ?

I reverted the CL because it was causing TestRegisters.test_fp_special_purpose_register_read to fail on OSX:

  • stop reason = EXC_BREAKPOINT
  • "register read ftag" yields 0x80 instead of expected 0x8000

Hi Abhishek,

please see my comments inline:

Hi Oleksiy

Thanks for pointing out. Two things:

  1. Is it possible for you to share the failure log for this test on MacOSX? The expected value of ftag is 0x0080 and not 0x8000. Which compiler was used to compile inferior?

I'm using clang 3.6

  1. Do you think that this patch needs reversion? In my opinion, this patch provides a much better (genric) way to test X87 FPU on Linux OS (atleast). I don't know whether the status for MacOSX would have even changed after you reverted this patch. I believe, it should still fail for MacOSX. I can take a look for MacOSX once you provide me failure logs. I would recommend to keep this patch and for the time being skip it for MacOSX. Once I find a fix for it on MacOSX, we can enable it for the same as well. What do you think ?

It makes sense to me to split fix in a few iterations:

  1. Submit the patch as-is just with XFAIL for Darwin (please check whether llvm.org/pr24733 is still relevant or it's failing on OSX due another error).
  2. Make a fix for Darwin if possible.