[PATCH] D39021: [llvm-objcopy] Add support for --only-keep and the special way it interacts with -O binary

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

In https://reviews.llvm.org/D39021#911688, @jhenderson wrote:

> Without thinking about it too much, the way I'd expect -j and -O binary to work is for it to be identical to -O binary with --remove-section for every other section, complete with padding being used to preserve alignment and relative positions etc (quick experiments shows this to be the case with GNU objcopy). That being said, I see that GNU objcopy has some unexpected behaviour when emitting binary output - the second of a pair of kept sections was neither aligned as it was in the input, nor positioned at the same relative distance to the first section, even though it was in the same segment.
>
> Tangentially related, I also see that we don't have any tests for what happens when you combine --remove-section etc with -O binary, and I doubt from my initial observation of GNU's behaviour that we match its behaviour. My initial instinct is therefore that the problem is with our binary output format, and that ultimately, we should be using the BinaryObject class in this case, after we've fixed it to match GNU's behaviour.


Hmmm. I definitely agree that we don't match GNU's behavior here. I'm also not sure we should but my primary hope would be that there is some sensible (e.g. everything is handled uniformly) behavior which is consistent in the kernel dumb case (if you have a bunch of contiguous segments output them contiguously) and in the section dump case. I also agree that whatever -j does it would be ideal if doing a --remove-section on everything else (sans .shstrtab, .symtab, and .strtab) did the same thing. That isn't currently the case, in fact -O basically just doesn't interact with the other options because it reads from the segment data directly. So that should likely change. I'll try and investigate what -O binary is doing precisely tomorrow (by looking at the code) so we can add a better account of what that's doing that what we get from treating it as a magical black box. I haven't a clue what it's doing but I'm not particularly convinced that it's sensible.

More concise summary of my thoughts on this

1. -O binary dosn't interact with other options in any way but it likely should
2. Matching GNU objcopy is favorable if GNU objcopy's behavior makes some degree of sense and isn't completely magical.
3. Even if we don't exactly match GNU objcopy I would like to find some sensible and consistent behavior for -O binary so that running -O binary on a single reasonably normal ELF agrees with GNU objcopy *and* when used in combination with -j or a bunch of -R options that do the same thing produces the same result. I can't seem to find an answer to that however.
4. I'll try and respond with precisely what GNU objcopy is doing in this case to see if that helps any.



================
Comment at: test/tools/llvm-objcopy/basic-only-keep.test:2
+# RUN: yaml2obj %s > %t
+# RUN: llvm-objcopy -j=.test %t %t2
+# RUN: llvm-readobj -file-headers -sections %t2 | FileCheck %s
----------------
jhenderson wrote:
> I've probably been inconsistent in requesting this for other switches in the past, but we should really test both aliases explicitly. A simple diff of the output when using -j and --only-keep would suffice for this.
Sounds good to me.


Repository:
  rL LLVM

https://reviews.llvm.org/D39021