[PATCH] D58116: [llvm-objcopy] Improve section removal

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

Some things that can go wrong if we allow segments to be modified such that their size or addresses change:

1. Dynamic relocations no longer patch the right area (potentially even patching memory outside the program's address space).
2. Dynamic tags could end up referencing incorrect addresses.
3. Code could end up referencing incorrect addresses.
4. The entry symbol may no longer point at a valid address.
5. Unlabelled space that has meaning (e.g. following section header stripping) may be discarded.

None of these are absolute reasons why we can't modify program headers, but I agree that we must have a concrete use case before we go ahead and implement manipulating phdrs in this way. I will say that it is probably safe to increase the size of a segment (both file and memory size), as long as the addresses of other segments are unaffected. This includes adding new segments entirely.

Using llvm-objcopy to reduce memory usage post-link seems like the wrong thing to do, because it can only safely remove sections that are known to be unused, and it's a bit of a sledge-hammer, because section concatenation has already been performed by the linker. A safer and much more appropriate place for this would be at link time, using switches such as --gc-sections. Using llvm-objcopy on the objects pre-link would also be possible here.

Removing empty segments is also sometimes not a no-op in terms of semantic behaviour (see e.g. the PT_GNU_STACK segment type). Even removing PT_LOAD segments may not be wise, since some loaders may explicitly expect a certain number of segments, although I agree that it is probably a feature that could be implemented, e.g. in via a switch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58116/new/

https://reviews.llvm.org/D58116