[llvm-dev] llvm-objcopy round-table summary

[James Henderson via llvm-dev]

Hi,

On Thursday of the recent developers meeting, we had a round-table
discussing llvm-objcopy. Below are some notes I took from that
meeting. The discussion was fairly free-flowing, so the notes are not
particularly in depth. If anybody has any other comments relating to
this meeting, feel free to add to this!

Feature request: converting from 32-bit ELF to 64-bit ELF:
-- Size in sections broken, needs updating to not just be a public
member variable.

Making llvm-objcopy into a library:
-- Errors need to be non-fatal (return llvm::Error).
-- Would be nice to provide this as a writable portion of libObject.

**Action**: James Henderson to provide results of feature comparison
versus GNU objcopy.

Multiple file formats:
-- Don't try to use a common intermediate representation for all
object file formats!
-- Separate backends for different file formats.
---- Would like to avoid people "forgetting" to implement some
switches when implementing a new backend, leading to silent ignoring
of switches (maybe use subclasses etc).
---- Shouldn't need to implement each option, beyond an "unsupported"
message or similar.

Output should be stable:
-- Currently not the case for section header table (is deterministic,
but might be unnecessarily different to input).
-- No need to go to heroic efforts, if not realistic, or a better
alternative is possible.

Discussion on being able to modify the program header table:
-- Jake reluctant to.
-- But if real use case presents itself, should be okay.
-- Some requirements to add segments post-link.
-- Embedded use-cases may well break the immutable program header
table requirement.

File bugs upstream for visibility:
-- **Action**: Jake Ehrlich to request himself, James Henderson,
Jordan Rupprecht, and Alexander Shaposhnikov (four current main
upstream developers/reviewers of llvm-objcopy) added as default-CC for
llvm-objcopy bugs.

Compatibility with GNU objcopy is a top concern:
-- Where diverged, believed that GNU behaviour doesn't make sense, but
open to alternative.
-- File bugs/propose changes if issues encountered.

Regards,

James