[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#903395, @jhenderson wrote:

> Diff context is missing.
>
> I noticed that gnu objcopy also keeps the symbol table when using -j, along with all the symbols in the kept section(s). Do you think we should match this behaviour as well?


I didn't realize this. I think it should be to match though. I'll make that change.

> Reading the documentation, gnu objcopy also allows -j to match using wildcards. Is this a use case you intend to support? (I'm happy for it to be a separate change, if you plan on doing it later).

Eventually I want to add section patterns for all the list like options but there's not a strong push for it from anyone right now so I'll wait. It should be easy enough to implement in a separate change however. I'm not sure if LLVM already has a wildcard patterns library but if not I can translate the pattern to a regex and match against that.

> Why can't we just use the standard BinaryObject class for the -O binary/-j use case?

-O bianry outputs per segment in llvm-objcopy not per section. GNU objcopy seems to reconstruct the program headers from the remaining sections. We would have to change -O binary to be more section oriented. It's not really clear how -O binary should work in llvm-objcopy in the presence of multiple sections with some removed however. For instance say that .foo and .bar are seperated by a few sections but are in the same segment. Should llvm-objcopy -j .foo -j .bar -O binary produce a file that contains them one right after the other? Or should it dump them separated by the proper amount with zeros in between (that seems more sensible to me)? How should alignment be handled when these two sections being kept? The first section can just be at the top because 0x0 has maximal alignment but if we separate the second section from the first by the desired amount then it's alignment might be wrong. Does this mean we should pad the front with zeros until we can fit both in the output? That last option (padding before and between) would be fully consistent with what -O binary does now but seems to produce a bizarre result. Another (possibly exactly same?) way of handeling it would be to say that -O binary should just output the ELF minus all headers and without the data from any non-allocated section. That would produce the strange gap of zeros at the end and be consistent and everything, it just doesn't seem sensible to me.

> As discussed in person at the LLVM conference last week, I'd support an alias for -O binary/-j to dump a single section raw to a file, e.g. something like "--copy-section". This can be done later though.

I think GNU objcopy has the --dump-section option for precisely this purpose. I plan on implementing that.


Repository:
  rL LLVM

https://reviews.llvm.org/D39021