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
CMakeLists.txt | ||
---|---|---|
236 | Nit: runtime -> executable |
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)
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.
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.
Nit: runtime -> executable