This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy][MachO] Fix segment's vmsize
ClosedPublic

Authored by alexander-shaposhnikov on Apr 24 2020, 1:12 AM.

Details

Summary

Fix the calculation of vmsize.

Test plan: make check-all

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: abrachet. · View Herald Transcript

Fix the calculation of vmsize.

Hope this can be expanded a bit to describe why the current code is wrong.

llvm/test/tools/llvm-objcopy/MachO/segments-vmsize.test
26

The long test (200+) makes it really unwieldy when we later want to reorganize tests. See ELF/ for some short examples. Can we simplify the YAML input a bit?

alexander-shaposhnikov marked an inline comment as done.Apr 24 2020, 9:56 AM
alexander-shaposhnikov added inline comments.
llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
161

@MaskRay: the issue was here. (VMSize += Sec->Size) - this is not correct (and it results in producing a broken binary),
also you can take a look at the newly added test and the comment therein. I've already mentioned in the past reviews that for tests containing sections it's error-prone to modify MachO yaml manually, even removing one seemingly unrelated load command triggers the recalculation of the offsets mentioned inside other load commands + the test is not really large, it's the minimal example which triggers the issue (because of the page alignment). Having a valid binary also enables us to use the existing tools from Xcode to validate / introspect the binary if necessary.

alexander-shaposhnikov marked an inline comment as done.Apr 24 2020, 10:01 AM
alexander-shaposhnikov added inline comments.
llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
161

to the best of my knowledge this test is not supposed to be reorganized, and if i'm not mistaken it should not even change (because it copies the binary without modifications). P.S. the test fails (as expected) without the fix.

alexander-shaposhnikov marked an inline comment as done.Apr 24 2020, 10:20 AM
alexander-shaposhnikov added inline comments.
llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
161

just to be clear: (what i mentioned on one of the previous diffs) i think one can refactor / consolidate the tests which verify that some load commands are supported and simply copied-over. Tests like this one (which are supposed to catch a particular issue
(on some reduced example) and the tests which verify a particular functionality should not be merged etc.

smeenai added inline comments.Apr 24 2020, 11:54 AM
llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
169

What purpose is the std::max serving here, given that VMSize is set to 0 before the loop and isn't modified inside the loop, as far as I can see?

alexander-shaposhnikov marked an inline comment as done.Apr 24 2020, 12:39 PM
alexander-shaposhnikov added inline comments.
llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
169

@smeenai - good question,
(if I'm not mistaken this code was influenced by the old LLD for MachO)
the sections listed in one LC_SEGMENT_64 load command in general appear to be not ordered by their virtual addresses.

P.S. I've also done a small experiment - one can see this happens for some object files created by llvm-mc

llvm-mc -assemble -triple x86_64-apple-darwin9 -filetype=obj Inputs/various-symbols.s -o real-world-input-copy.test.tmp.various-symbols.o
llvm-readobj --sections real-world-input-copy.test.tmp.various-symbols.o ...

This LGTM. I'll let @MaskRay sign off too.

llvm/tools/llvm-objcopy/MachO/MachOLayoutBuilder.cpp
169

Ah, that makes sense.

MaskRay accepted this revision.Apr 24 2020, 2:44 PM

LGTM as well.

This revision is now accepted and ready to land.Apr 24 2020, 2:44 PM
This revision was automatically updated to reflect the committed changes.