ar and objcopy/strip all support configuring whether archives are written deterministically (timestamps/UIDs/GIDs/etc zero'd). This has been ported to llvm-ar (the U/D modifiers) but not yet to llvm-objcopy/strip.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I feel it should be enabled by default, as deterministic build is a very nice property.
It was before this patch and it still is. This is providing the option to make it not default (if anyone wants that), and also won't break if someone is explicitly running "objcopy --enable-deterministic-archives" and we drop llvm-objcopy in place of that.
I can add a test case for that, actually.
It was before this patch and it still is. This is providing the option to make it not default (if anyone wants that), and also won't break if someone is explicitly running "objcopy --enable-deterministic-archives" and we drop llvm-objcopy in place of that.
Oh sorry I didn't notice that. What was the motivation for you to add a new flag so that you can choose deterministic and non-deterministic? (Just wondering.)
These flags exist in GNU strip/objcopy/ar (see [man strip]), so it isn't really "new".
If we convert users of strip to llvm-strip, they will break if they are specifying --enable-determinstic-archives and this flag is not defined.
I do not see any problem of adding these flags for the sake of compatibility with GNU. What I wondered is whether or not you really have a need to make it nondeterministic. I thought that we might be able to just ignore these flags.
Personally, I think that if the default is to make them deterministic, then I don't see any reason not to allow overriding this default, as the code does not become significantly more complex with this change. However, I could be persuaded that nobody has this use case.
test/tools/llvm-objcopy/deterministic-archive.test | ||
---|---|---|
22–25 ↗ | (On Diff #171842) | Missing llvm-strip equivalents? |
28–29 ↗ | (On Diff #171842) | Ditto. |
tools/llvm-objcopy/CopyConfig.cpp | ||
348–349 ↗ | (On Diff #171842) | Is this what GNU objcopy does? I'd actually expect this to be a "last one wins" scenario (similar to various --[no-]some-option in LLD etc. |
425–426 ↗ | (On Diff #171842) | Same comment as above. |
Ditto -- sorry for not understanding the comment earlier.
I only have a use case for explicitly setting deterministic archives. I don't have a use case for non-deterministic archives, although I could imagine some build systems maybe want it (for preserving timestamps). At any rate, it's trivial to provide. I think the onus is on someone providing evidence that exposing this option is *harmful*.
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
348–349 ↗ | (On Diff #171842) | I thought it was simpler to just error instead of match objcopy, but it actually comes to fewer lines implementing last-one-wins. Done. |
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
348–349 ↗ | (On Diff #171842) | You don't need to use the filtered and loop method at all, you can just use the hasFlag method, which takes both a positive and negative option: I think this is right (various LLD options are implemented this way): Config->DeterministicArchives(OOBJCOPY_enable_deterministic_archvies, OBJCOPY_disable_deterministic_archives, /*default*/true); |
tools/llvm-objcopy/ObjcopyOpts.td | ||
42 ↗ | (On Diff #171966) | Somebody pointed out in an llvm-objdump review (see D53804) that Alias options are not in the help text by default (they are hidden), but they really should be. This might want to be a wider issue for us to fix at some point though, but in the meantime, perhaps you should add these particular ones? What do you think? |
tools/llvm-objcopy/CopyConfig.cpp | ||
---|---|---|
348–349 ↗ | (On Diff #171842) | Oh, I didn't see that method. Even shorter now, thanks! :) |
tools/llvm-objcopy/ObjcopyOpts.td | ||
42 ↗ | (On Diff #171966) | Agreed that --help is terrible. It also bothers me that we print help for both "--foo=value" and "--foo value". Fixed for these ones. |
LGTM.
Might want to wait to see if @ruiu or anybody else has any other comments though.