This is an archive of the discontinued LLVM Phabricator instance.

[LLDB][PPC64] Fix single step and LldbGdbServer tests
ClosedPublic

Authored by luporl on Feb 26 2018, 9:23 AM.

Details

Summary

On PPC64, the tested functions were being entered through their local entry point, while the tests expected the program to stop at the function start address, that, for PPC64, corresponds to the global entry point.

To fix the issue, the test program was modified to call the functions to be tested through function pointers, which, on PPC64, force the calls through the global entry point, while not affecting the test on other platforms.

Diff Detail

Repository
rL LLVM

Event Timeline

luporl created this revision.Feb 26 2018, 9:23 AM
luporl added subscribers: lbianc, alexandreyy.
labath requested changes to this revision.Feb 26 2018, 9:42 AM

I think we should find some other way to fix this. Is there a way to force the inferior to go through the global entry point? Would putting the function in a different compilation unit help? Or calling it through a function pointer?

This revision now requires changes to proceed.Feb 26 2018, 9:42 AM

I think we should find some other way to fix this. Is there a way to force the inferior to go through the global entry point? Would putting the function in a different compilation unit help? Or calling it through a function pointer?

Yes, there are some ways to force the inferior to go through the global entry point.

Simply putting the function in a different compilation unit won't help, because the linker is able to optimize calls to functions to use the local entry point if the object files get linked together.
I guess this would work only if the function is put in a different shared object.

Calling the function through a pointer seems to work, at least in my test program.
Can I change the test to always perform the call through a function pointer on all platforms?

Can I change the test to always perform the call through a function pointer on all platforms?

Yes, these test only care that we are actually able to hit a breakpoint that we set, they don't care about how we actually get to that point. We could even generate some assembly and put a breakpoint there if that would make things easier. (It would probably be even better, as some of the tests here already depend on exact counts of assembly instructions, etc.)

luporl updated this revision to Diff 136120.Feb 27 2018, 11:32 AM
  • Merge branch 'master' into fix-tests-brkpts
  • Forcing PPC64 to use function global entry point

Also, there were two tests that started failing after last merge with master,
that assumed that a generic FP register would always exist.
These were fixed as well.

labath accepted this revision.Feb 27 2018, 11:45 AM
This revision is now accepted and ready to land.Feb 27 2018, 11:45 AM
luporl updated this revision to Diff 137020.Mar 5 2018, 9:10 AM
  • Merge branch 'master' into fix-tests-brkpts

This fixes some minor conflicts with latest ppc64 patches merged into master.

luporl added a comment.Mar 7 2018, 6:22 AM

Thank you @labath. Can you check this in for me?

labath added a comment.Mar 7 2018, 6:27 AM

Please update the patch description to what you want the commit message to say. (e.g., it this case the description is obsolete and very unhelpful to anyone who would be reading it in the future). I just noticed that I've already committed a couple of patches from you guys with not-so-ideal commit messages.

luporl edited the summary of this revision. (Show Details)Mar 7 2018, 7:43 AM
This revision was automatically updated to reflect the committed changes.