[PATCH] D41619: [llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary

[Jake Ehrlich via Phabricator via llvm-commits]

jakehehrlich added a comment.

This change as is might cause us to fail the following requirement

> As ``Program Loading'' describes in this chapter of the processor supplement, loadable process segments must have congruent values for p_vaddr and p_offset, modulo the page size. This member gives the value to which the segments are aligned in memory and in the file. Values 0 and 1 mean no alignment is required. Otherwise, p_align should be a positive, integral power of 2, and p_vaddr should equal p_offset, modulo p_align.

If PAddr and VAddr differ modulo Align then this change will cause the above to be violated and there's no getting around that with this sort of solution. If this bug is to be fixed it will need to be with code that violates the above invariant in some principled way and it isn't clear to me what that principle should be. One principal that should I think should not be violated is that if EI_OSABI is ELFOSABI_NONE (e.g. System V) then the above alignment constraint should always be respected. This leaves room if EI_OSABI is something else for this requirement to change. I'm not sure how exactly that should be handled though.

Additionally as long as EI_OSABI is ELFOSABI_NONE PAddr is not a defined value per the following

> On systems for which physical addressing is relevant, this member is reserved for the segment's physical address. Because System V ignores physical addressing for application programs, this member has unspecified contents for executable files and shared objects.

So as is this change does not seem acceptable to me.


https://reviews.llvm.org/D41619