[PATCH] D67689: [llvm-objcopy] Add support for --gap-fill and --pad-to options

[Hui Huang via Phabricator via llvm-commits]

Hui added a comment.

Some observations on the following sample sample.o with GNU objcopy.

  Seg1:                      0x108   0x10F
                                   |  .gap1  |
  
  Seg2: 0x100       0x102    0x108   0x10F        0x110   0x114      0x116
         | .space1   | .nogap | .gap1 |  .space2   | .gap2 |  .space3 |
  
  Seg3: 0x200     0x204    0x20A        0x212
         | .space4 |  .foo  |            | .nobit_bss |
  
  Seg4: 0x200                              0x218
         | .nobit_tbss                      |



In D67689#1680465 <https://reviews.llvm.org/D67689#1680465>, @jhenderson wrote:

> One major question to answer is how should --gap-fill interact with the preserving of segment contents that llvm-objcopy follows when segment contents are not covered by existing sections (see llvm/test/tools/llvm-objcopy/preserve-segment-contents.test for an example of the behaviour). I'd be inclined to have --gap-fill overwrite the data in this case, in which case a test should be written to show that the old data is no longer written in this case (see below for more details).
>
> Some other questions/comments:
>
> 1. What should be the behaviour for gaps between the start of a segment and the start of the first section? I feel like --gap-fill should fill that gap too (same goes for end of the section and segment).


GNU filled .space2, .space3 and .space4, leaving .space1 and spaces at 0x20A -0x212 unchanged. I think it's exactly what GNU objcopy means for filling gaps between loadable sections. We could fill .space1 (if llvm-objcopy specific).

> 2. In relation to the preserve contents issue above, what should happen if a section is removed? Currently it fills it with zeroes. I think it should instead fill it with --gap-fill bytes (see `writeSegmentData`).

This is a concern. Currently with the following command. the -R option will overwrite --gap-fill. You are right. The main reason is that the removal of sections is done in `writeSegmentData` after the --gap-fill patch. 
llvm-objcopy.exe sample.o sf --regex -R .space.* --gap-fill=0xe9

> 3. For --gap-fill, I think a simpler approach than what you have might be to change how Segments are written in `writeSegmentData`: if --gap-fill is not specified, use the existing contents of the segment, otherwise use --gap-fill's value.

Since the section and segment could be resized via --gap-fill,  their file offsets need to be recalculated ahead of `writeSegmentData`, i.e via `layoutSegmeent` etc.

> 4. For --pad-to, what should happen with SHT_NOBITS sections? The description you've written suggests that they should have their size increased to pad to the corresponding address, but this isn't the behaviour I see with GNU objcopy.



> 5. Also for --pad-to, I feel like your code is more complicated than it needs to be. I feel like the relevant changes would be most appropriate in or immediately before layoutSegments - identify what the last segment is and then resize it and the last section in it. I don't think you need to create new sections or segments, although you'll need to identify how you can increase the size.
> 6. What does GNU objcopy do for non-progbits sections that are last in the loadable segment, e.g. .dynamic sections?



> 7. What does GNU objcopy do if the last such section is nested inside multiple segments (e.g. because it's a TLS section)? I expect it to resize all such segments, which might not be trivial to achieve using llvm-objcopy's current architecture (sections are only in the top-most parent segment, and don't know about other segments they are in).




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

https://reviews.llvm.org/D67689