[PATCH] D33964: [LLVM][llvm-objcopy] Added basic plumbing to get things started

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In https://reviews.llvm.org/D33964#803969, @jakehehrlich wrote:

> In https://reviews.llvm.org/D33964#803460, @jhenderson wrote:
>
> > Could you construct a test case that confirms the behaviour of nested segments, please? Something with a memory image like:
> >
> >   | Segment 1                                                        |
> >   | Segment 2                               |
> >   | Progbits Section | gap | NOBITS section | gap | Progbits section |  
> >
>
>
> I can confirm this just won't work right. As is the first Progbits section will wind up in two Segments and everything will get all messed up. For this diff I'm fine with that not being supported.  I'm also not sure what the intended behavior is in this case.


I'm ok with that as well, but I'd like to understand what your plan is going forward to fix this, in case it has a significant impact on the design.

Having a progbits section in multiple segments is absolutely fine, and I'd expect the layout to be maintained as in the diagram. The alignment of all containing segments needs to be respected when placing the first section, and then they all start at the same place (or in the case where the nested segment is not at the start, at the same relative offset). There are some weird oddities when coming to NOBITS sections, because of their file/memory footprint mismatch. The simple, but probably undesirable, option is to allocate a file footprint for any NOBITS sections that are not at the end of the top-most parent segment. I think though that actually, as is the case in the diagram here, that there is special handling for nested NOBITS sections like this in loaders (specifically, I'm thinking of the .tbss case again - the example could easily be a data segment with a nested TLS segment, with the .tdata, .tbss, and .data sections). By my understanding, as long as .tbss is at the end of the nested TLS segment, it should not have a file footprint, even though it makes it look like there'll be a mismatch in the data segment.



================
Comment at: test/tools/llvm-objcopy/hello-world.s:2
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+# RUN: ld.lld %t.o -o %t
+# RUN: llvm-objcopy %t %t2
----------------
jakehehrlich wrote:
> jhenderson wrote:
> > I don't think this will work for many people, as LLD is not part of LLVM's main source code body, so people will be unable to run this test. That being said, I'm not sure how to work around this. Can yaml2obj help us here? (I'm not particularly familiar with that tool yet).
> Oh man, that didn't even occur to me. As far as I am aware there is no way to produce program headers using yaml2obj. It never produces any program headers by default either. I think you're right and this should be fixed. I have no clue how to fix it other than adding support for program headers to yaml2obj. That's not something I've looked into however.
> 
> Perhaps there is a way to require lld for this test? That way it's just unsupported for most people?
I'm afraid I don't know of a way. There might be, but if there is, somebody else will have to advise.

It seems to me that having program header support in yaml2obj is very desirable. I'd offer to add it, but I do not have any time to do so.


Repository:
  rL LLVM

https://reviews.llvm.org/D33964