This is an archive of the discontinued LLVM Phabricator instance.

Support Linux on SystemZ as platform
ClosedPublic

Authored by uweigand on Apr 11 2016, 11:32 AM.

Details

Summary

This patch adds support for Linux on SystemZ:

  • A new ArchSpec value of eCore_s390x_generic
  • A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
  • Register context support
  • Native Linux support including watchpoint support
  • ELF core file support
  • Misc. support throughout the code base (e.g. breakpoint opcodes)
  • Test case updates to support the platform

This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).

There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).

The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:

  • We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets.
  • SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changes those to simply use plain write watchpoints. ]

This patch depends on D18977 to add the CFAOffset ABI callback.

Diff Detail

Repository
rL LLVM

Event Timeline

uweigand updated this revision to Diff 53293.Apr 11 2016, 11:32 AM
uweigand retitled this revision from to Support Linux on SystemZ as platform.
uweigand updated this object.
uweigand added reviewers: labath, tberghammer, clayborg.
uweigand added a subscriber: lldb-commits.
clayborg requested changes to this revision.Apr 11 2016, 1:48 PM
clayborg edited edge metadata.

Just a few questions on why read watchpoints were being disabled in the few SBValue::Watch() calls. Other than that it looks good. Is it possible to revert the read watchpoint changes, or is it needed for SystemZ?

packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_events/TestWatchpointEvents.py
62 ↗(On Diff #53293)

I realize this test isn't actually using the watchpoint, it is just testing it, but why is this change needed? Does SystemZ not support read watchpoints or something?

packages/Python/lldbsuite/test/python_api/watchpoint/TestWatchpointIter.py
61 ↗(On Diff #53293)

This test just tests hitting writes to a variable, but why is this change needed? Does SystemZ not support read watchpoints or something?

This revision now requires changes to proceed.Apr 11 2016, 1:48 PM
clayborg accepted this revision.Apr 11 2016, 3:10 PM
clayborg edited edge metadata.

Ok, then setting write only watchpoints should be fine for those tests/

This revision is now accepted and ready to land.Apr 11 2016, 3:10 PM
labath edited edge metadata.Apr 12 2016, 3:41 AM

Could you also add a core file test to TestLinuxCore? It should be a matter of running make_core.sh, saving the files and creating a new test function in the file (I've tried to make it simple, if you see room for improvement, then let me know).

I think this is especially important as probably noone here has access to this hardware, so this will enable the rest of the developers to run at least a basic sanity check on their changes.

packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
36 ↗(On Diff #53293)

We generally expectedFailure for things which we consider an lldb bug, and skip for cases when the test simply does not apply. Platform not having enough watchpoints sounds like the latter case. I see you were simply copying the mips case (which does not follow this either), and it doesn't really matter to me, but I just wanted to make you aware of that.

Could you also add a core file test to TestLinuxCore? It should be a matter of running make_core.sh, saving the files and creating a new test function in the file (I've tried to make it simple, if you see room for improvement, then let me know).

I think this is especially important as probably noone here has access to this hardware, so this will enable the rest of the developers to run at least a basic sanity check on their changes.

Yes, that seems to work fine. I'll add those files with the next update.

We generally expectedFailure for things which we consider an lldb bug, and skip for cases when the test simply does not apply. Platform not having enough watchpoints sounds like the latter case. I see you were simply copying the mips case (which does not follow this either), and it doesn't really matter to me, but I just wanted to make you aware of that.

So I guess my thought was that in theory, there may be ways to support multiple watchpoints. In particular, while the hardware only supports a single watchpoint, this may span an address range of arbitrary length. So it may be possible to implement two or more watchpoints by registering a watchpoint range with the hardware that spans all the areas that need to be watched. However, when the hardware then reports a watchpoint hit, we'd have to find out which of the original watchpoints is affected, and ignore cases where we get false positives due to hits elsewhere in the range. This is in fact implemented in GDB, so it should be possible. But an LLDB implementation of this idea seems a bit more complex, and certainly not something I wanted to include in the initial submission ...

uweigand updated this revision to Diff 53593.Apr 13 2016, 11:03 AM
uweigand edited edge metadata.

Updated to provide ABI::GetFallbackRegisterLocation instead of ABI::CFAOffset.

Added core file test.

labath accepted this revision.Apr 14 2016, 1:31 AM
labath edited edge metadata.

That's perfect, thanks a lot. :)

Do you have commit access? If not, let me know when you're ready to start landing these things...

This revision was automatically updated to reflect the committed changes.

That's perfect, thanks a lot. :)

Do you have commit access? If not, let me know when you're ready to start landing these things...

I do have commit access, and have committed the 10 out of 12 patches that are approved as of today. This means current mainline should support Linux on SystemZ as target pretty well. Due to the two patches still missing, I'm still seeing three test suite failures: TestNoreturnUnwind.py and TestInferiorAssert.py fail due to missing D18975, and TestCppScope.py fails due to missing D18976.

Otherwise, everything is looking good. Thanks to everybody for your support in getting this in!

labath added a subscriber: labath.Apr 14 2016, 8:37 AM

Hi,

this has broken basically everything on 32-bit targets
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/13413.
Will you be able to track down the problem quickly? I don't expect the
fix to be complicated, but if we can't track it down quickly (1-2
hours?) we should start pulling out the offending changes...

pl