This is an archive of the discontinued LLVM Phabricator instance.

Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission
ClosedPublic

Authored by jakehehrlich on Nov 8 2017, 3:33 PM.

Details

Reviewers
beanz
phosek
Summary

llvm-objcopy is getting to where it can be used in non-trivial ways (such as for dwarf fission in clang). It now supports dwarf fission but this feature hasn't been thoroughly tested yet. This change allows people to optionally build clang to use llvm-objcopy rather than GNU objcopy. By default GNU objcopy is still used so nothing should change.

Diff Detail

Repository
rL LLVM

Event Timeline

jakehehrlich created this revision.Nov 8 2017, 3:33 PM
Hahnfeld added inline comments.
CMakeLists.txt
236

Nit: runtime -> executable

phosek accepted this revision.Nov 10 2017, 12:30 AM

LGTM

This revision is now accepted and ready to land.Nov 10 2017, 12:30 AM

I think the current tests will only pass iff the executable name ends with objcopy - can we make this more reliable?

jakehehrlich added a comment.EditedNov 10 2017, 10:35 AM

I think the current tests will only pass iff the executable name ends with objcopy - can we make this more reliable?

If I read the tests (split-debug.h, split-debug.c, and split-debug.s) correctly they check for the existence of the word "objcopy" somewhere in the executables name. I'm not sure how to make it anymore flexible than that. The right thing to do would be to somehow get the string from CMake and use that in this test. I'm not sure of llvm-lit supports any kind of find and replace like that however.

Ideally it would look like

// CHECK: ${DEFAULT_OBJCOPY}{{.*}}--extract-dwo{{.*}}"split-debug.dwo"

And llvm-lit would replace every occurence of ${DEFAULT_OBJCOPY} with the the value it pulled from CMAKE_DEFAULT_OBJCOPY (the way that it gets host and target information)

I think the current tests will only pass iff the executable name ends with objcopy - can we make this more reliable?

If I read the tests (split-debug.h, split-debug.c, and split-debug.s) correctly they check for the existence of the word "objcopy" somewhere in the executables name. I'm not sure how to make it anymore flexible than that. The right thing to do would be to somehow get the string from CMake and use that in this test. I'm not sure of llvm-lit supports any kind of find and replace like that however.

Right you are, I must have missed {{.*}} at the end. Another option would be to restrict CLANG_DEFAULT_OBJCOPY to contain objcopy or even to only allow objcopy or llvm-objcopy. I don't know if that's sensible though...

Another option would be to restrict CLANG_DEFAULT_OBJCOPY to contain objcopy or even to only allow objcopy or llvm-objcopy. I don't know if that's sensible though...

I think there are some other strip/objcopy like implementations out there but I think objcopy and llvm-objcopy are the only ones that support --extract-dwo and --strip-dwo right now but more could come. I think objcopy and llvm-objcopy are the only ones that have "objcopy" in the name so the current test kind of enforces that one of them must be used. Also the user might want to pull objcopy or llvm-objcopy from a specific place on their system (not just from PATH) so however we restrict this, it will have to be much more general than just allowing "objcopy" or "llvm-objcopy". That said restricting the set of program names seems reasonable to me since you should in theory be able to add your program to the CMakeList.txt check on CLANG_DEFAULT_OBJCOPY if you want clang to support it. I don't think any other implementation of objcopy is likely to exist anytime soon though so it seems kind of moot to me.

jakehehrlich closed this revision.Nov 13 2017, 2:33 PM

This has already landed, I'm not sure why it wasn't automatically closed.

It wasn't automatically closed because the commit (https://reviews.llvm.org/rL317960) referenced the wrong differential in its Differential Revision field. Not sure how that happened.