[PATCH] D78005: [yaml2obj] - Reimplement how tool calculates memory sizes of segments.

[James Henderson via Phabricator via llvm-commits]

jhenderson added inline comments.


================
Comment at: llvm/test/tools/yaml2obj/ELF/program-header-nobits.yaml:26-27
+## This segment includes sections 1 to 6.
+# NOOFFSET-NEXT: LOAD 0x000000 0x0000000200000000 0x0000000200000000 0x000200 0x000500
+# OFFSET-NEXT:   LOAD 0x000158 0x0000000200000000 0x0000000200000000 0x0000a8 0x0003a8
+## This segment includes sections 1 to 5.
----------------
jhenderson wrote:
> grimar wrote:
> > jhenderson wrote:
> > > Something's not right here. Why is the memory size 0x500/0x3a8?
> > > 
> > > The highest end address of any section in the segment is 0x2000003b0, according to the section dump above, which would mean a size of 0x508/0x3b0 depending on which offset is used as the start point.
> > > 
> > > This might be because you've specified section addresses which conflict with the program header address, causing confusion - the program header with Offset 0 can't have the same VAddr as its first section, since the first section doesn't start at offset 0.
> > I've adjusted the VAddr.
> I don't think it's possible to share things the way you are. All your VAddr adjustment has done is to reduce the values slightly. The cause of the problem is still there.
> 
> For the offset 0 case, according to the section header table the first section is at address "0x00000001fffffea8". Meanwhile, the segmetns have the same address. However, the two do not share the same offset. Therefore, you end up with an input layout that looks like the following according to the two tables:
> 
> ```
> 1fffffea8
> | Sec1 | Sec2 | ... |
> | Seg1               |
> ...
> ```
> 
> whereas in offset terms you have:
> 
> ```
> 0                                  158
> | Elf Header | Phdr table | Sec1 | Sec2 | ... |
> | Seg1                                                   |
> ```
> 
> which means the address of Sec1 will effectively be calculated by the loader etc as 0x00000001fffffea8 + 0x158, which isn't what the section's claimed address is.
> 
> You won't be able to share the section's addresses in this way between the two modes, because the relative offset of the first section in the segments is going to be different between the two cases.
Urrggh, my examples got messed up a little (the 158 should line up with Sec1, not Sec2), but hopefully my point should be clear.


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

https://reviews.llvm.org/D78005