[PATCH] D36558: [llvm-objcopy] Add support for nested and overlapping segments

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 18 05:54:07 PDT 2017


jhenderson added a comment.

In https://reviews.llvm.org/D36558#868749, @jakehehrlich wrote:

> Sorry about not getting that changed faster. That's just not ok. I apologize.
>
> As for the FileSize < MemSize issue. The standard states "The file size may not be larger than the memory size" here: http://www.sco.com/developers/gabi/2012-12-31/ch5.pheader.html
>
> I haven't seen anything producing any such binaries. Also LLD considers it a bug when it happens so that's at least one linker that promises to never do it. I think I'd rather throw an error on read in if this happens. Would that be ok?


No problem, it happens. Sorry for getting back to you slowly - I've been on annual leave for a few days.

That standard quote only refers to PT_LOAD segments. Other segment types are not constrained by this, so the new error will spuriously catch such cases. We cannot rely on the linker preventing this case for other segment types, because it is entirely reasonable for specific targets to have segments that are not loaded on the target, so don't need address or memory size allocated - see the "NOLOAD" linker script directive, for example. I could also imagine a target which does not assign addresses for the ELF header/program header table, but theoretically they could be assigned to a (non-loaded) segment.

Ultimately though, I think this is all irrelevant - the actual problem here is the use of alignTo with zero alignment, but according to the ELF spec, a value of 0 or 1 means no alignment, so if we see an align of zero, we should align as if aligning to 1, I think.


Repository:
  rL LLVM

https://reviews.llvm.org/D36558





More information about the llvm-commits mailing list