This is an archive of the discontinued LLVM Phabricator instance.

[sanitizer] [SystemZ] Implement internal_clone.
ClosedPublic

Authored by koriakin on Apr 15 2016, 7:05 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

koriakin retitled this revision from to [sanitizer] [SystemZ] Implement internal_clone..
koriakin updated this object.
koriakin set the repository for this revision to rL LLVM.
koriakin added a project: Restricted Project.
koriakin added a subscriber: llvm-commits.
kcc added a subscriber: kcc.Apr 15 2016, 9:32 AM

General question: is SystemZ a variant of Linux?
If not, such changes should not go to files named *_linux*.cc, instead they should go into separate files names *_systemz.cc
Same is true even if SystemZ *is* a Linux variant, but a significantly different from the regular one.

More generally, please prefer a separate file to multiple #ifdefs.

In D19159#402595, @kcc wrote:

General question: is SystemZ a variant of Linux?
If not, such changes should not go to files named *_linux*.cc, instead they should go into separate files names *_systemz.cc
Same is true even if SystemZ *is* a Linux variant, but a significantly different from the regular one.

More generally, please prefer a separate file to multiple #ifdefs.

SystemZ is a CPU (also known as z/Series, or s390x), not an OS.

kcc added a comment.Apr 15 2016, 11:51 AM

Ok. We already have files with suffix aarch64 or aarch64.
Please try to follow this rule: do not add any new #ifdef unless

  1. the ifdef is a single top-level ifdef in a separate file
  2. you are adding an #elif to an already existing #ifdef/#elif sequence.
In D19159#402783, @kcc wrote:

Ok. We already have files with suffix aarch64 or aarch64.
Please try to follow this rule: do not add any new #ifdef unless

  1. the ifdef is a single top-level ifdef in a separate file
  2. you are adding an #elif to an already existing #ifdef/#elif sequence.

Well, technically the outer #elif in this patch does follow the rule (the inner ones don't, but they're much better justified).

Anyhow, here's the plan:

  1. Revert the AvoidCVE... patch (it's not doing much good without ASan/MSan/TSan support anyhow).
  2. Submit a patch creating sanitizer_linux_s390.cc and moving internal_mmap there.
  3. Resubmit this patch with a dep on #2.
  4. Resubmit AvoidCVE... patch with empty AvoidCVE...() in common code and with a dep on #2.

I have one more patch in queue that adds s390-specific code which will end up in sanitizer_linux_s390.cc, but it's going to be a while before I get all dependencies merged.

kcc edited edge metadata.Apr 25 2016, 1:28 PM

Wasn't this commited already?

In D19159#411114, @kcc wrote:

Wasn't this commited already?

Nope, you may be thinking of internal_mmap, not internal_clone.

kcc accepted this revision.Apr 25 2016, 5:47 PM
kcc edited edge metadata.

LGTM.

Note that I did not try hard to review the s390 code as I don't know (nor care) about it enough.
Feel free to submit patches to files fully covered under ifdef SANITIZER_S390 w/o my review,
although I would recommend to find a reviewer who knows the s390 stuff.

This revision is now accepted and ready to land.Apr 25 2016, 5:47 PM
This revision was automatically updated to reflect the committed changes.