This is an archive of the discontinued LLVM Phabricator instance.

[ELF][PPC64] Add --lax-call-lacks-nop
AbandonedPublic

Authored by MaskRay on Jan 3 2020, 2:28 PM.

Details

Reviewers
sfertile
ruiu
espindola
Group Reviewers
Restricted Project

Diff Detail

Event Timeline

MaskRay created this revision.Jan 3 2020, 2:28 PM
MaskRay retitled this revision from [ELF][PPC64] Add --laxed-call-lacks-nop to [ELF][PPC64] Add --lax-call-lacks-nop.Jan 3 2020, 2:28 PM

Unit tests: pass. 61237 tests passed, 0 failed and 729 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

MaskRay updated this revision to Diff 236145.Jan 3 2020, 3:53 PM

Add a hint. Add a test (we have to work around a MC deficiency)

MaskRay updated this revision to Diff 236146.Jan 3 2020, 3:54 PM

Forgot to add the test

Unit tests: pass. 61237 tests passed, 0 failed and 729 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Unit tests: pass. 61238 tests passed, 0 failed and 729 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

ruiu added inline comments.Jan 5 2020, 10:36 PM
lld/ELF/InputSection.cpp
980–984

Can this condition be reduced to

!config->laxCallLacksNop && rel.sym->file != file &&
(bufLoc + 8 > bufEnd || read32(bufLoc + 4) != 0x60000000)

?

lld/ELF/Options.td
225

Does this mean "GCC 5.4 or earlier AND GCC 6.4 or earlier"? Did you mean GCC 5.4 to 6.4?

MaskRay updated this revision to Diff 236298.Jan 5 2020, 11:18 PM
MaskRay marked 3 inline comments as done.

Update help message

Unit tests: pass. 61251 tests passed, 0 failed and 736 were skipped.

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

ruiu added inline comments.Jan 6 2020, 12:27 AM
lld/ELF/Options.td
225

I"m confused. Doesn't "GCC 5.4 or earlier AND GCC 6.4 or earlier" just mean "GCC 5.4 or earlier"?

MaskRay marked an inline comment as done.Jan 6 2020, 12:38 AM
MaskRay added inline comments.
lld/ELF/InputSection.cpp
980–984

It can't.

rel.sym->file == file is the case we want to ignore when --lax-call-lacks-nop is specified.

So we use !(config->laxCallLacksNop && rel.sym->file == file) here.

lld/ELF/Options.td
225

Each major version has a release branch. This was fixed in 7 (not released at that time), then back ported to the release branches of 5 and 6. So certain 5.* and 6.* releases do not include the patch.

ruiu added inline comments.Jan 6 2020, 12:48 AM
lld/ELF/InputSection.cpp
980–984

OK. Can you factor out config->laxCallLacksNop && rel.sym->file == file as a boolean variable?

lld/ELF/Options.td
225

How about something like "GCC 5.0-5.6 and GCC 6.0-6.4"?

MaskRay updated this revision to Diff 236307.Jan 6 2020, 12:54 AM
MaskRay marked 3 inline comments as done.

Update help message

Unit tests: fail. 61245 tests passed, 6 failed and 736 were skipped.

failed: LLVM-Unit.ADT/_/ADTTests/APFloatTest.DecimalStringsWithoutNullTerminators
failed: Clang Tools.clang-tidy/checkers/readability-magic-numbers-bitfields.cpp
failed: Clang Tools.clang-tidy/checkers/readability-magic-numbers.cpp
failed: Clang Tools.clang-tidy/readability-magic-numbers-userliteral.cpp
failed: libc++.std/thread/thread_mutex/thread_mutex_requirements/thread_mutex_requirements_mutex/thread_mutex_recursive/lock.pass.cpp
failed: libc++.std/thread/thread_mutex/thread_mutex_requirements/thread_mutex_requirements_mutex/thread_mutex_recursive/try_lock.pass.cpp

clang-tidy: fail. Please fix clang-tidy findings.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Thanks for doing this. I think this approach in much safer at the cost of some friction on the systems where the option is needed. My one suggestion would be to separate the tail call case b foo from the normal call case. It will cause a runtime failure if the callers caller resides outside the dso and would be much more likely then a failure like glibc encountered. I believe gcc/gfortran got that case correct so it shouldn't impact usability on the older OS releases, but I'm not 100% sure of that.

MaskRay abandoned this revision.May 26 2021, 5:46 PM