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

[asmith]

Summary

This adds two new options to match GNU objcopy:

--gap-fill is used to fill gaps between two adjacent loadable sections with a specified 8 bit value.
--pad-to will pad the last loadable section to the pad-to address with the value specified by --gap-fill if present or zero by default.

Overview of how this works in llvm-objcopy:

1. Resize all the segments if needed.
2. Adjust section/segment layout (i.e. file offset) due to overlap across sections in the same segment or overlap across segments.
3. Set the parent segment's content.
4. Set the segment child's content.
5. Set the section's content.

[asmith]

Any comments from the llvm-objcopy community?

[seiya]

Commented regarding tests and nits. Could you update docs/CommandGuide/llvm-objcopy.rst as well?

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

Is it possible to use yaml2obj instead of adding a binary file? I think we just need few sections to make sure that this patch works well. For example (not tested):

!ELF
FileHeader:
  Class:           ELFCLASS64
  Data:            ELFDATA2LSB
  Type:            ET_EXEC
  Machine:         EM_X86_64
Sections:
  - Name:            .text
    Type:            SHT_PROGBITS
    Content:         "AABBCCDD"
  - Name:            .foo
    Type:            SHT_PROGBITS
    Content:         "EEFF"
  - Name:            .bar
    Type:            SHT_NOBITS

llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp

632

nit: please avoid auto and use uint64_t.

633

ditto

642

ditto

[asmith]

Address reviewers comments about auto

[asmith]

Add new options to objcopy documentation

[asmith]

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

That's a good suggestion. Will look into that.

[Hui]

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

This patch resizes the section and its containing segments. (Parent or child segment). One main part of the test is to check the section to segment mapping from PHDR. However yam2obj can't keep program headers.

[jhenderson]

Thinks for the patch! I haven't had time to review the meat of it yet, but will try to get back to it in the next couple of days. One quick question in the meantime: what's the motivation behind this? Is it to improve GNU compatibility?

llvm/docs/CommandGuide/llvm-objcopy.rst

81

I think you can change this slightly to "... to the ''<address>'' ...", using the formatting of the reference to <section> in --only-section above (i.e. back ticks instead of apostrophes).

82

:option:''--gap-fill'' (using backticks instead of apostrophes)

llvm/include/llvm/Object/ELF.h

408

This and a couple of tests look like an unrelated change?

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

2

Why does this and the other tests require shell? I don't see anything in here that requires it (od and cmp are both available in GnuWin32 tools for example).

3

We tend in the newer binary tools tests to use '##' for comments to separate them from test commands. Please could you update.

5

This patch resizes the section and its containing segments. (Parent or child segment). One main part of the test is to check the section to segment mapping from PHDR. However yam2obj can't keep program headers.

I'm not sure I understand what you mean here? yaml2obj supports program headers (it has done for a couple of years now I think). See for example llvm/test/tools/yaml2obj/program-header.yaml etc as well as various llvm-objcopy tests using program headers (e.g. llvm/test/tools/llvm-objcopy/segment-test-remove-section.test).

llvm/tools/llvm-objcopy/CopyConfig.cpp

566

addr -> Addr

I'm guessing this and the above error return Expected. Would you mind not using auto here to make it clear, please?

[Hui]

llvm/include/llvm/Object/ELF.h

408

This diagnostic message probably emitted when the layout of resized sections was not correctly done. However it is misleading. The 'Size' is supposed to be in hex while it is not.

[asmith]

In D67689#1679198, @jhenderson wrote:

Thinks for the patch! I haven't had time to review the meat of it yet, but will try to get back to it in the next couple of days. One quick question in the meantime: what's the motivation behind this? Is it to improve GNU compatibility?

I need these options to use llvm-objcopy when building uboot.

llvm/include/llvm/Object/ELF.h

408

This is a bug fix. The value wasn’t printed correctly.

[Hui]

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

You are right. Actually I was then thinking about using obj2yaml to get yaml file and operate it with yaml2obj in the test. Unfortunately obj2yaml hasn't supported dumping the program headers (A plausible easy feature to have but not in position yet). So no output about PHDR by yam2obj.

[asmith]

Address comments on comment character #, auto and rst file.

[jhenderson]

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).
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).
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.
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).

llvm/include/llvm/Object/ELF.h

408

I agree it's a bug fix, but it's a bug fix not directly related to this issue. Please create a separate patch for it.

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

In general, we prefer to create the YAML file by hand, as obj2yaml output for an object is significantly more verbose than is required to test the behaviour. If after looking at existing examples of how to write program headers for yaml2obj, you need more assistance in creating a test input, I'm happy to help - I've had plenty of experience crafting them to test odd cases.

llvm/tools/llvm-objcopy/ObjcopyOpts.td

234

This line is too long and should be broken up over multiple lines, like the other switch names. I think there's a clang-format invocation to do that for tablegen files, but I'm not sure what it is.

[jakehehrlich]

--gap-fill should likely overwrite all interstitial data which includes data at the end of loadable segments not just the data between sections that we previously preserved. I view the --gap-fill use case as being a use case for things like lld's trap filling. Yes this violates the strict interpretation of "don't overwrite segment contents" but its ok in this case I think. Making binaries more secure is a good thing!

--pad-to is more tricky and requires altering the segment size which I'm not so fond of. We have to ensure that sections never fall outside of a segment or overlap another section when this happens.

[jakehehrlich]

What's the use case for these two flags? Where has it come up in actual practice that these were needed? I think they basically exist to cover an issue left by the linker that lld no longer leaves. I'm particularly hesitant to add --pad-to

[jakehehrlich]

"Interstitial data" is data covered by by a segment but not a section. Gap fill should IMO set the bytes for all of that space. This is consistent with James's recommendation how things work. --pad-to when padding to a page aligned address this can for instance ensure that all executable bytes contain either valid code or a trap instruction.

Another axiom I'd like to hold if possible for the use case: no new segment overlapping should occur and its an error if --pad-to causes this. Technically this is valid and can occur and the internals handle it so I'm not adding a hard no here.

Dear god lets throw an error for now if this has to touch a TLS segment/sections...thats a crazy rabit whole where the rules for how everything works change. When someone hits that case we can think about it then.

If the last PT_LOAD segment memsize and filesize don't agree then using -pad-to is invalid and should be be an error.

I'm still not satisfied I've thought of all the error conditions so expect more as I think about this more carefully.

llvm/tools/llvm-objcopy/ObjcopyOpts.td

229

I'd say "set all bytes not covered by an allocated section but covered by a PT_LOAD segment to <val>" or something explicit to that effect. Reading GNU objcopy's format agnostic documentation is far too vauge to guess the results of.

234

We should be explict and say "pad the last SHF_ALLOC section ...."

[Hui]

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, @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).

[srhines]

@asmith, are you still working on this patch? The gap-fill feature is definitely needed for parity with existing objcopy implementations.

[asmith]

@srhines Not at the moment. I updated the PR with the changes I have locally.

[jhenderson]

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

2

"regression tests" means different things to different people. Simply "tests" is sufficient here.

21

You don't need to explicitly create a YAML with sections that get stripped to create the gaps in them. You can use the yaml2obj "Fill" pseudo-section type. It works the same way as regular sections, but no section header is created in the output for it, so the output looks like it has gaps. You just list it as a Section, with the required size in the Sections list, and Type: Fill. See llvm\test\tools\yaml2obj\ELF\custom-fill.yaml for example usage.

42

181–185

It would be easier to follow the test if you put these checks up where they are used for the first time.

llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp

657

Nit: don't forget to run clang-format on the code you modify.

[asmith]

addressed reviewer comments

[jhenderson]

I'm out of time to review this further, but there's plenty of comments to take a look at. Also adding a couple more reviewers who might be able to help out.

llvm/docs/CommandGuide/llvm-objcopy.rst

69

Presumably you meant bytes, not bits?

81–82

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

5

8

22

This tends to be preferred in newer tests.

24

I'm not convinced this sanity test is worthwhile, since that just shows that yaml2obj or llvm-readelf are broken, whereas this is a test for llvm-objcopy.

36–37

You might also want a variant of this test with --gap-fill last.

48

49

What's the point of this line?

50

It's not clear in what way this is truncated. You need to show the actual behaviour here too. You could do this by picking a value that truncates to the same value as a "normal" test and then using cmp to show that the output is identical. The "normal" test output will still need verifying to show the right output has been emitted.

55–56

And then change SHDR/PHDR below to CHECK. (Note: I can't remember whether program headers or section headers appear first - you may need to change the order of the two check blocks around to match).

It is not obvious from the comments in this test or the documentation that --gap-fill changes the size of sections. This is actually slightly strange behaviour to me. Are you sure it reflects what GNU objcopy does? If it is, please improve the documentation to say that the filling is achieved by padding the tail of sections, and probably also explain what is expected in the test comments.

59–67

The majority of this data is not relevant to the test. I suggest removing the columns that aren't important. For those at the start or end, you can simply omit them. For those in between columns you want to check (name, offset, size probably), you can just use {{.*}} to indicate a regex matching anything.

69

This comment appears to be referring to a potential problem with GNU objcopy? If so, it's not really relevant, and the comment could rot if the behaviour in GNU objcopy is fixed/changes.

94

Don't you also need to check that the value is correct?

96

I think it would be a good idea to show how a multi-byte value is written too, especially in relation to being truncated if the gap size isn't a multiple of the specified value.

100

Make sure to add full stops to the end of all comments.

119

Don't use grep in tests. See https://llvm.org/docs/TestingGuide.html#writing-new-regression-tests.

Could you just arrange your sections to be closer together so that you don't need such a large amount to check? You could then easily check using od.

124–139

We usually try to remove excessive space between the key and value in YAML, to make it a little easier to read (the edit suggestion is just partial, the same sort of edit applies throughout). You also don't need this many fields - AddressAlign defaults to 0/1 (I forget which, but they are semantically the same here), Size is auto-derived from the Content if not specified, and Address is automatically calculated based on the segment VAddr, IIRC. Get rid of the excess here and below.

142

The SHF_EXECINSTR is not relevant to the test, so get rid of it to make the test simpler. Same goes below - the TLS bit is probably not relevant to the test (NOBITS might be on the other hand).

166

187

Do you actually need any content here? It's not clear what the purpose of this section is.

189–195

This generates illegal ELF. The gABI dictates that PT_LOAD segments must be in ascending address order. Please move this segment accordingly.

llvm/test/tools/llvm-objcopy/ELF/pad-to.test

2

Looks like this test is missing a comment explaining the purpose of the test.

3

5

Why? (Please expand the comment to explain the reason)

27

How about --pad-to=0x204 for testing the edge case?

45–47

See my comment about not using grep in the --gap-fill test.

52

54

As above - don't use grep.

58–60

This can be combined into a single command, as suggested in the other test.

77

Same comments as gap-fill.test re. reducing what's in the YAML to a more minimal amount.

llvm/tools/llvm-objcopy/CopyConfig.cpp

563

564–565

This needs testing.

567

Are you sure this is supposed to be truncated to a uint8_t and not say a 4-byte word or similar that is repeated?

llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp

596–603

You need testing to show why this sorting is necessary.

617–620

This isn't the way to do this. A) as the name implies, OriginalData is intended to be immutable (maybe it should be const). Changing it changes llvm-objcopy's view of what the section originally had for data. B) This looks like a memory leak - you new an array and then create an ArrayRef to it, but there's nothing cleaning up the memory afterwards.

Take a look at OwnedDataSection. It's likely you'll want something like this. Alternatively, you could add a field to the SectionBase class called "AddedData" or something like that which is written after the rest of the section's data.

On a related note, beware of other section types like dynamic sections. I don't know if GNU objcopy changes the size of such sections. If it does, we'll need to too, but the logic for such sections is different in llvm-objcopy, so may need additional handling and testing.

[alanphipps]

This review appears to have stalled. Is anything missing as a result of the more recent comments to complete it? Thanks!

[jhenderson]

In D67689#3047955, @alanphipps wrote:

This review appears to have stalled. Is anything missing as a result of the more recent comments to complete it? Thanks!

I don't think anybody is actively working on this patch anymore. It's probably a candidate for somebody else to pick it up and continue the work.

[nickdesaulniers]

Looks like this is needed for building u-boot.

[jhenderson]

Just a related note that D112116 is adding support for --update-section. This is related to --gap-fill and --pad-to, should anybody ever pick back up the work to implement either of these options:

• For --gap-fill, it should overwrite the gap left behind should the updated section be shrunk.
• The current implementation of --update-section won't allow increasing a section in segment's size. However, technically, it's possible to increase the size of the last section (see also the --pad-to option). It may be possible to leverage the code used for --pad-to to support the limitation of --update-section too.

llvm/docs/CommandGuide/llvm-objcopy.rst

  this to a subset of the local symbols. For example, file and section symbols in
  ELF objects will not be discarded.
 
 .. option:: --enable-deterministic-archives, -D
 
  Enable deterministic mode when copying archives, i.e. use 0 for archive member
  header UIDs, GIDs and timestamp fields. On by default.
 
+.. option:: --gap-fill <value>
+
+ Fill gaps between two adjacent loadable sections with 8 bit ``<value>``.
+
 .. option:: --help, -h
 
  Print a summary of command line options.
 
 .. option:: --only-section <section>, -j
 
  Remove all sections from the output, except for sections named ``<section>``.
  Can be specified multiple times to keep multiple sections.
 
+.. option:: --pad-to <address>
+
+ Pad the last loadable section to ``<address>`` using a value of zero or
+ the value specified by :option:`--gap-fill`.
+
 .. option:: --regex
 
  If specified, symbol and section names specified by other switches are treated
  as extended POSIX regular expression patterns.
 
 .. option:: --remove-section <section>, -R
 
  Remove the specified section from the output. Can be specified multiple times

llvm/include/llvm/Object/ELF.h

if (Size % sizeof(T))
     return createError("section " + getSecIndexForError(this, Sec) +
                        " has an invalid sh_size (" + Twine(Size) +
                        ") which is not a multiple of its sh_entsize (" +
                        Twine(Sec->sh_entsize) + ")");
   if ((std::numeric_limits<uintX_t>::max() - Offset < Size) ||
       Offset + Size > Buf.size())
     return createError("section " + getSecIndexForError(this, Sec) +
                        " has a sh_offset (0x" + Twine::utohexstr(Offset) +
-                       ") + sh_size (0x" + Twine(Size) +
+                       ") + sh_size (0x" + Twine::utohexstr(Size) +
                        ") that cannot be represented");
 
   if (Offset % alignof(T))
     // TODO: this error is untested.
     return createError("unaligned data");
 
   const T *Start = reinterpret_cast<const T *>(base() + Offset);
   return makeArrayRef(Start, Size / sizeof(T));

llvm/test/Object/invalid.test

- Name: .shstrtab
     Size: 0
 
 ## Check that llvm-objdump reports an error when .shstrtab has an invalid
 ## size that goes past the end of the file.
 
 # RUN: not llvm-objdump -s %p/Inputs/invalid-strtab-size.elf 2>&1 \
 # RUN:   | FileCheck %s -DFILE=%p/Inputs/invalid-strtab-size.elf --check-prefix=INVALID-STRTAB-SIZE
 
-# INVALID-STRTAB-SIZE: error: '[[FILE]]': section [index 1] has a sh_offset (0x70) + sh_size (0x16777215) that cannot be represented
+# INVALID-STRTAB-SIZE: error: '[[FILE]]': section [index 1] has a sh_offset (0x70) + sh_size (0xffffff) that cannot be represented
 
 ## Check that llvm-dwarfdump reports an error during relocation resolution
 ## when instead of expected SHT_RELA section it locates a section of a different type.
 
 # RUN: yaml2obj %s --docnum=3 -o %t3
 # RUN: not llvm-dwarfdump -debug-line %t3 2>&1 | FileCheck --check-prefix=RELA %s
 
 # RELA: LLVM ERROR: Section is not SHT_RELA
- Name:     .rela
     ShOffset: 0x10000
 
 ## Check that llvm-objdump reports an error when .shstrtab has a broken sh_offset
 ## so large that sh_offset + sh_size overflows the platform address size type.
 
 # RUN: yaml2obj %s --docnum=14 -o %t14
 # RUN: not llvm-readobj --symbols %t14 2>&1 | FileCheck -DFILE=%t14 --check-prefix=INVALID-SECTION-SIZE2 %s
 
-# INVALID-SECTION-SIZE2: error: '[[FILE]]': section [index 1] has a sh_offset (0xffffffff) + sh_size (0x27) that cannot be represented
+# INVALID-SECTION-SIZE2: error: '[[FILE]]': section [index 1] has a sh_offset (0xffffffff) + sh_size (0x1b) that cannot be represented
 
 --- !ELF
 FileHeader:
   Class:   ELFCLASS64
   Data:    ELFDATA2LSB
   Type:    ET_REL
   Machine: EM_386
 Sections:

llvm/test/tools/llvm-objcopy/ELF/gap-fill.test

+## Tests for --gap-fill option.
+## clang-7 gapfillpadto.cpp -o gapfillpadto.elf
+## void swap(int *a, int *b) {
+##  int temp = *b;
+##  *b = *a;
+##  *a = temp;
+## }
+## int main() {
+##   int a = 10;
+##   int b = 1;
+##   swap(&a, &b);
+##  return a;
+## }
+
+
+# RUN: llvm-objcopy %p/Inputs/gapfillpadto.elf %t
+# RUN: not llvm-objcopy --gap-fill %t 2>&1 | FileCheck %s --check-prefix=EMPTY
+# RUN: not llvm-objcopy --gap-fill= %t 2>&1 | FileCheck %s --check-prefix=BAD-FORMAT
+# RUN: not llvm-objcopy --gap-fill=x %t 2>&1 | FileCheck %s --check-prefix=BAD-INPUT
+# RUN: not llvm-objcopy --gap-fill=0x1G %t 2>&1 | FileCheck %s --check-prefix=BAD-INPUT2
+
+## Verify truncating is not allowed.
+# RUN: not llvm-objcopy --gap-fill=0x1122 %t 2>&1 | FileCheck %s --check-prefix=BAD-NUMBER
+
+## Verify the headers are expected.
+# RUN: llvm-objcopy --gap-fill=0xe9 %t %t-filled
+# RUN: llvm-readelf -h %t-filled | FileCheck %s --check-prefix=FHDR
+# RUN: llvm-readelf -S %t-filled | FileCheck %s --check-prefix=SHDR
+# RUN: llvm-readelf -l %t-filled | FileCheck %s --check-prefix=PHDR
+
+## Verify the following section contents are not altered.
+# RUN: llvm-objcopy -j .interp -j .note.ABI-tag -j .note.gnu.build-id -j .gnu_version_r -j .rodata \
+# RUN:   -j .eh_frame_hdr -j .init_array -j .fini_array -j .got -j .got.plt -O binary %t %t1
+# RUN: llvm-objcopy -j .interp -j .note.ABI-tag -j .note.gnu.build-id -j .gnu_version_r -j .rodata \
+# RUN:   -j .eh_frame_hdr -j .init_array -j .fini_array -j .got -j .got.plt -O binary %t-filled %t2
+# RUN: cmp %t1 %t2
+# RUN: llvm-objcopy -j .dynsym -j .rela.dyn -j .dynamic --allow-broken-links -O binary %t %t3
+# RUN: llvm-objcopy -j .dynsym -j .rela.dyn -j .dynamic --allow-broken-links -O binary %t-filled %t4
+# RUN: cmp %t3 %t4
+
+## Verify all section gaps are filled with 0xe9. The verification is done by two steps:
+##   First read the section original data and ensure they are not altered.
+##   Second, read the gaps and ensure they have the filled value.
+# RUN: llvm-objcopy -j .init -O binary %t %t.init
+# RUN: llvm-objcopy -j .init -O binary %t-filled %t-filled.init
+# RUN: od -v -Ax -x -N 0x17 %t.init > %t.init1
+# RUN: od -v -Ax -x -N 0x17 %t-filled.init > %t.init2
+# RUN: cmp %t.init1 %t.init2
+# RUN: od -v -Ax -t x1 -j 0x17 -N 1 %t-filled.init | FileCheck %s --check-prefix=INIT
+
+# RUN: llvm-objcopy -j .fini -O binary %t %t.fini
+# RUN: llvm-objcopy -j .fini -O binary %t-filled %t-filled.fini
+# RUN: od -v -Ax -x -N 0x9 %t.fini > %t.fini1
+# RUN: od -v -Ax -x -N 0x9 %t-filled.fini > %t.fini2
+# RUN: cmp %t.fini1 %t.fini2
+# RUN: od -v -Ax -t x1 -j 0x9 -N 3 %t-filled.fini | FileCheck %s --check-prefix=FINI
+
+# RUN: llvm-objcopy -j .text -O binary %t %t.text
+# RUN: llvm-objcopy -j .text -O binary %t-filled %t-filled.text
+# RUN: od -v -Ax -x -N 0x1d2 %t.text > %t.text1
+# RUN: od -v -Ax -x -N 0x1d2 %t-filled.text > %t.text2
+# RUN: cmp %t.text1 %t.text2
+# RUN: od -v -Ax -t x1 -j 0x1d2 -N 2 %t-filled.text | FileCheck %s --check-prefix=TEXT
+
+# RUN: llvm-objcopy -j .gnu.hash --allow-broken-links -O binary %t %t.hash
+# RUN: llvm-objcopy -j .gnu.hash --allow-broken-links -O binary %t-filled %t-filled.hash
+# RUN: od -v -Ax -x -N 0x1c %t.hash > %t.hash1
+# RUN: od -v -Ax -x -N 0x1c %t-filled.hash > %t.hash2
+# RUN: cmp %t.hash1 %t.hash2
+# RUN: od -v -Ax -t x1 -j 0x1c -N 4 %t-filled.hash | FileCheck %s --check-prefix=HASH
+
+# RUN: llvm-objcopy -j .dynstr --allow-broken-links -O binary %t %t.dynstr
+# RUN: llvm-objcopy -j .dynstr --allow-broken-links -O binary %t-filled %t-filled.dynstr
+# RUN: od -v -Ax -x -N 0x5f %t.dynstr > %t.dynstr1
+# RUN: od -v -Ax -x -N 0x5f %t-filled.dynstr > %t.dynstr2
+# RUN: cmp %t.dynstr1 %t.dynstr2
+# RUN: od -v -Ax -t x1 -j 0x5f -N 1 %t-filled.dynstr | FileCheck %s --check-prefix=DYNSTR
+
+# RUN: llvm-objcopy -j .gnu.version --allow-broken-links -O binary %t %t.ver
+# RUN: llvm-objcopy -j .gnu.version --allow-broken-links -O binary %t-filled %t-filled.ver
+# RUN: od -v -Ax -x -N 0x6 %t.ver > %t.ver1
+# RUN: od -v -Ax -x -N 0x6 %t-filled.ver > %t.ver2
+# RUN: cmp %t.ver1 %t.ver2
+# RUN: od -v -Ax -t x1 -j 0x6 -N 2 %t-filled.ver | FileCheck %s --check-prefix=VER
+
+# RUN: llvm-objcopy -j .eh_frame -O binary %t %t.ehf
+# RUN: llvm-objcopy -j .eh_frame -O binary %t-filled %t-filled.ehf
+# RUN: od -v -Ax -x -N 0xf8 %t.ehf > %t.ehf1
+# RUN: od -v -Ax -x -N 0xf8 %t-filled.ehf > %t.ehf2
+# RUN: cmp %t.ehf1 %t.ehf2
+# Read 0x200738 bytes (equals to 0x200830-0xf8, i.e 2099000)
+# RUN: od -v -An -t x1 -j 0xf8 -N 2099000 %t-filled.ehf | grep "e9" | wc -w | FileCheck %s --check-prefix=EHF
+
+## Verify the last loadable section is not altered.
+# RUN: llvm-objcopy -j .data -O binary %t %t.data
+# RUN: llvm-objcopy -j .data -O binary %t-filled %t-filled.data
+# RUN: cmp %t.data %t-filled.data
+
+# EMPTY: no input file specified
+# BAD-FORMAT: bad number for --gap-fill:
+# BAD-INPUT: bad number for --gap-fill: x
+# BAD-INPUT2: bad number for --gap-fill: 0x1G
+# BAD-NUMBER: bad number for --gap-fill: 0x1122
+
+# FHDR: Start of section headers:          2103536 (bytes into file)
+
+# SHDR: Section Headers:
+# SHDR:    [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
+# SHDR:    [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
+# SHDR:    [ 1] .interp           PROGBITS        0000000000400238 000238 00001c 00   A  0   0  1
+# SHDR:    [ 2] .note.ABI-tag     NOTE            0000000000400254 000254 000020 00   A  0   0  4
+# SHDR:    [ 3] .note.gnu.build-id NOTE           0000000000400274 000274 000024 00   A  0   0  4
+# SHDR:    [ 4] .gnu.hash         GNU_HASH        0000000000400298 000298 000020 00   A  5   0  8
+# SHDR:    [ 5] .dynsym           DYNSYM          00000000004002b8 0002b8 000048 18   A  6   1  8
+# SHDR:    [ 6] .dynstr           STRTAB          0000000000400300 000300 000060 00   A  0   0  1
+# SHDR:    [ 7] .gnu.version      VERSYM          0000000000400360 000360 000008 02   A  5   0  2
+# SHDR:    [ 8] .gnu.version_r    VERNEED         0000000000400368 000368 000020 00   A  6   1  8
+# SHDR:    [ 9] .rela.dyn         RELA            0000000000400388 000388 000030 18   A  5   0  8
+# SHDR:    [10] .init             PROGBITS        00000000004003b8 0003b8 000018 00  AX  0   0  4
+# SHDR:    [11] .text             PROGBITS        00000000004003d0 0003d0 0001d4 00  AX  0   0 16
+# SHDR:    [12] .fini             PROGBITS        00000000004005a4 0005a4 00000c 00  AX  0   0  4
+# SHDR:    [13] .rodata           PROGBITS        00000000004005b0 0005b0 000004 04  AM  0   0  4
+# SHDR:    [14] .eh_frame_hdr     PROGBITS        00000000004005b4 0005b4 00003c 00   A  0   0  4
+# SHDR:    [15] .eh_frame         PROGBITS        00000000004005f0 0005f0 200830 00   A  0   0  8
+# SHDR:    [16] .init_array       INIT_ARRAY      0000000000600e20 200e20 000008 08  WA  0   0  8
+# SHDR:    [17] .fini_array       FINI_ARRAY      0000000000600e28 200e28 000008 08  WA  0   0  8
+# SHDR:    [18] .dynamic          DYNAMIC         0000000000600e30 200e30 0001c0 10  WA  6   0  8
+# SHDR:    [19] .got              PROGBITS        0000000000600ff0 200ff0 000010 08  WA  0   0  8
+# SHDR:    [20] .got.plt          PROGBITS        0000000000601000 201000 000018 08  WA  0   0  8
+# SHDR:    [21] .data             PROGBITS        0000000000601018 201018 000010 00  WA  0   0  8
+# SHDR:    [22] .bss              NOBITS          0000000000601028 201028 000008 00  WA  0   0  1
+# SHDR:    [23] .comment          PROGBITS        0000000000000000 201028 000078 01  MS  0   0  1
+# SHDR:    [24] .symtab           SYMTAB          0000000000000000 2010a0 000588 18     25  41  8
+# SHDR:    [25] .strtab           STRTAB          0000000000000000 201628 0001cc 00      0   0  1
+# SHDR:    [26] .shstrtab         STRTAB          0000000000000000 2017f4 0000f9 00      0   0  1
+
+# PHDR: Program Headers:
+# PHDR:  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
+# PHDR:  PHDR           0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R   0x8
+# PHDR:  INTERP         0x000238 0x0000000000400238 0x0000000000400238 0x00001c 0x00001c R   0x1
+# PHDR:      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
+# PHDR:  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x200e20 0x200e20 R E 0x200000
+# PHDR:  LOAD           0x200e20 0x0000000000600e20 0x0000000000600e20 0x000208 0x000210 RW  0x200000
+# PHDR:  DYNAMIC        0x200e30 0x0000000000600e30 0x0000000000600e30 0x0001c0 0x0001c0 RW  0x8
+# PHDR:  NOTE           0x000254 0x0000000000400254 0x0000000000400254 0x000044 0x000044 R   0x4
+# PHDR:  GNU_EH_FRAME   0x0005b4 0x00000000004005b4 0x00000000004005b4 0x00003c 0x00003c R   0x4
+# PHDR:  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+# PHDR:  GNU_RELRO      0x200e20 0x0000000000600e20 0x0000000000600e20 0x0001e0 0x0001e0 R   0x1
+
+# INIT: 000017 e9
+# FINI: 000009 e9 e9 e9
+# TEXT: 0001d2 e9 e9
+# HASH: 00001c e9 e9 e9 e9
+# DYNSTR: 00005f e9
+# VER: 000006 e9 e9
+# EHF: 2099000

llvm/test/tools/llvm-objcopy/ELF/pad-to.test

+# RUN: llvm-objcopy %p/Inputs/gapfillpadto.elf %t
+# RUN: not llvm-objcopy --pad-to %t 2>&1 | FileCheck %s --check-prefix=EMPTY
+# RUN: not llvm-objcopy --pad-to= %t 2>&1 | FileCheck %s --check-prefix=BAD-FORMAT
+# RUN: not llvm-objcopy --pad-to=x %t 2>&1 | FileCheck %s --check-prefix=BAD-INPUT
+# RUN: not llvm-objcopy --pad-to=0x1G %t 2>&1 | FileCheck %s --check-prefix=BAD-INPUT2
+# RUN: not llvm-objcopy --pad-to=0x112233445566778899 %t 2>&1 | FileCheck %s --check-prefix=BAD-NUMBER
+
+## The last loadable section is .data (0x601018 - 0x601028).
+## Verify that nothing is done if provided any pad-to address lower than 0x601028.
+# RUN: llvm-objcopy --pad-to=0x20 %t %t-p1
+# RUN: cmp %t %t-p1
+# RUN: llvm-objcopy --pad-to=0x600000 %t %t-p2
+# RUN: cmp %t %t-p2
+# RUN: llvm-objcopy --pad-to=0x601011 %t %t-p3
+# RUN: cmp %t %t-p3
+
+## Pad .data to a valid address.
+# RUN: llvm-objcopy --pad-to=0x601101 %t %t-pad
+
+## Verify the following section contents are not altered.
+# RUN: llvm-objcopy -j .interp -j .note.ABI-tag -j .note.gnu.build-id -j .gnu_version -j .gnu_version_r \
+# RUN:   -j .init -j .fini -j .rodata -j .eh_frame_hdr -j .eh_frame -j .init_array -j .fini_array \
+# RUN:   -j .got -j .got.plt -O binary %t %t1
+# RUN: llvm-objcopy -j .interp -j .note.ABI-tag -j .note.gnu.build-id -j .gnu_version -j .gnu_version_r \
+# RUN:   -j .init -j .fini -j .rodata -j .eh_frame_hdr -j .eh_frame -j .init_array -j .fini_array \
+# RUN:   -j .got -j .got.plt -O binary %t-pad %t2
+# RUN: cmp %t1 %t2
+# RUN: llvm-objcopy -j .gnu_hash -j .dynstr -j .dynsym -j .rela.dyn -j .dynamic --allow-broken-links -O binary %t %t3
+# RUN: llvm-objcopy -j .gnu_hash -j .dynstr -j .dynsym -j .rela.dyn -j .dynamic --allow-broken-links -O binary %t-pad %t4
+# RUN: cmp %t3 %t4
+
+## Verify .data is padded to the address 0x601101 with a default value 0.
+# RUN: llvm-objcopy -j .data -O binary %t %t.data
+# RUN: llvm-objcopy -j .data -O binary %t-pad %t-pad.data
+# RUN: od -v -Ax -x -N 0x10 %t.data > %t.data1
+# RUN: od -v -Ax -x -N 0x10 %t-pad.data > %t.data2
+## The original data is not altered.
+# RUN: cmp %t.data1 %t.data2
+## .data is padded from 0x601028-0x601101. Read 0xd9 bytes (equals to 0x601101 - 0x601028, i.e 217)
+# RUN: od -v -An -t x1 -j 0x10 -N 217 %t-pad.data | grep "00" | wc -w | FileCheck %s --check-prefix=DATA
+
+## Verify the headers are expected.
+# RUN: llvm-readelf -h %t-pad | FileCheck %s --check-prefix=FHDR
+# RUN: llvm-readelf -S %t-pad | FileCheck %s --check-prefix=SHDR
+# RUN: llvm-readelf -l %t-pad | FileCheck %s --check-prefix=PHDR
+
+# EMPTY: no input file specified
+# BAD-FORMAT: bad address for --pad-to:
+# BAD-INPUT: bad address for --pad-to: x
+# BAD-INPUT2: bad address for --pad-to: 0x1G
+# BAD-NUMBER: bad address for --pad-to: 0x112233445566778899
+
+# FHDR: Start of section headers:          6608 (bytes into file)
+
+# SHDR:   Section Headers:
+# SHDR:    [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
+# SHDR:    [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
+# SHDR:    [ 1] .interp           PROGBITS        0000000000400238 000238 00001c 00   A  0   0  1
+# SHDR:    [ 2] .note.ABI-tag     NOTE            0000000000400254 000254 000020 00   A  0   0  4
+# SHDR:    [ 3] .note.gnu.build-id NOTE           0000000000400274 000274 000024 00   A  0   0  4
+# SHDR:    [ 4] .gnu.hash         GNU_HASH        0000000000400298 000298 00001c 00   A  5   0  8
+# SHDR:    [ 5] .dynsym           DYNSYM          00000000004002b8 0002b8 000048 18   A  6   1  8
+# SHDR:    [ 6] .dynstr           STRTAB          0000000000400300 000300 00005f 00   A  0   0  1
+# SHDR:    [ 7] .gnu.version      VERSYM          0000000000400360 000360 000006 02   A  5   0  2
+# SHDR:    [ 8] .gnu.version_r    VERNEED         0000000000400368 000368 000020 00   A  6   1  8
+# SHDR:    [ 9] .rela.dyn         RELA            0000000000400388 000388 000030 18   A  5   0  8
+# SHDR:    [10] .init             PROGBITS        00000000004003b8 0003b8 000017 00  AX  0   0  4
+# SHDR:    [11] .text             PROGBITS        00000000004003d0 0003d0 0001d2 00  AX  0   0 16
+# SHDR:    [12] .fini             PROGBITS        00000000004005a4 0005a4 000009 00  AX  0   0  4
+# SHDR:    [13] .rodata           PROGBITS        00000000004005b0 0005b0 000004 04  AM  0   0  4
+# SHDR:    [14] .eh_frame_hdr     PROGBITS        00000000004005b4 0005b4 00003c 00   A  0   0  4
+# SHDR:    [15] .eh_frame         PROGBITS        00000000004005f0 0005f0 0000f8 00   A  0   0  8
+# SHDR:    [16] .init_array       INIT_ARRAY      0000000000600e20 000e20 000008 08  WA  0   0  8
+# SHDR:    [17] .fini_array       FINI_ARRAY      0000000000600e28 000e28 000008 08  WA  0   0  8
+# SHDR:    [18] .dynamic          DYNAMIC         0000000000600e30 000e30 0001c0 10  WA  6   0  8
+# SHDR:    [19] .got              PROGBITS        0000000000600ff0 000ff0 000010 08  WA  0   0  8
+# SHDR:    [20] .got.plt          PROGBITS        0000000000601000 001000 000018 08  WA  0   0  8
+# SHDR:    [21] .data             PROGBITS        0000000000601018 001018 0000e9 00  WA  0   0  8
+# SHDR:    [22] .bss              NOBITS          0000000000601028 001101 000008 00  WA  0   0  1
+# SHDR:    [23] .comment          PROGBITS        0000000000000000 001101 000078 01  MS  0   0  1
+# SHDR:    [24] .symtab           SYMTAB          0000000000000000 001180 000588 18     25  41  8
+# SHDR:    [25] .strtab           STRTAB          0000000000000000 001708 0001cc 00      0   0  1
+# SHDR:    [26] .shstrtab         STRTAB          0000000000000000 0018d4 0000f9 00      0   0  1
+
+# PHDR: Program Headers:
+# PHDR:  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
+# PHDR:  PHDR           0x000040 0x0000000000400040 0x0000000000400040 0x0001f8 0x0001f8 R   0x8
+# PHDR:  INTERP         0x000238 0x0000000000400238 0x0000000000400238 0x00001c 0x00001c R   0x1
+# PHDR:      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
+# PHDR:  LOAD           0x000000 0x0000000000400000 0x0000000000400000 0x0006e8 0x0006e8 R E 0x200000
+# PHDR:  LOAD           0x000e20 0x0000000000600e20 0x0000000000600e20 0x0002e1 0x0002e9 RW  0x200000
+# PHDR:  DYNAMIC        0x000e30 0x0000000000600e30 0x0000000000600e30 0x0001c0 0x0001c0 RW  0x8
+# PHDR:  NOTE           0x000254 0x0000000000400254 0x0000000000400254 0x000044 0x000044 R   0x4
+# PHDR:  GNU_EH_FRAME   0x0005b4 0x00000000004005b4 0x00000000004005b4 0x00003c 0x00003c R   0x4
+# PHDR:  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+# PHDR:  GNU_RELRO      0x000e20 0x0000000000600e20 0x0000000000600e20 0x0001e0 0x0001e0 R   0x1
+
+# DATA: 217

llvm/tools/llvm-objcopy/CopyConfig.h

struct CopyConfig {
   // Advanced options
   StringRef AddGnuDebugLink;
   // Cached gnu_debuglink's target CRC
   uint32_t GnuDebugLinkCRC32;
   StringRef BuildIdLinkDir;
   Optional<StringRef> BuildIdLinkInput;
   Optional<StringRef> BuildIdLinkOutput;
   Optional<StringRef> ExtractPartition;
+  Optional<uint8_t> GapFill;
+  Optional<uint64_t> PadTo;
   StringRef SplitDWO;
   StringRef SymbolsPrefix;
   StringRef AllocSectionsPrefix;
   DiscardType DiscardMode = DiscardType::None;
   Optional<uint8_t> NewSymbolVisibility;
 
   // Repeated options
   std::vector<StringRef> AddSection;

llvm/tools/llvm-objcopy/CopyConfig.cpp

if (InputArgs.hasArg(OBJCOPY_build_id_link_output))
     Config.BuildIdLinkOutput =
         InputArgs.getLastArgValue(OBJCOPY_build_id_link_output);
   Config.SplitDWO = InputArgs.getLastArgValue(OBJCOPY_split_dwo);
   Config.SymbolsPrefix = InputArgs.getLastArgValue(OBJCOPY_prefix_symbols);
   Config.AllocSectionsPrefix =
       InputArgs.getLastArgValue(OBJCOPY_prefix_alloc_sections);
   if (auto Arg = InputArgs.getLastArg(OBJCOPY_extract_partition))
     Config.ExtractPartition = Arg->getValue();
-
+  if (auto Arg = InputArgs.getLastArg(OBJCOPY_gap_fill)) {
+    // Truncation is not allowed.
+    ErrorOr<uint8_t> Val = getAsInteger<uint8_t>(Arg->getValue());
+    if (!Val)
+      return createStringError(Val.getError(), "bad number for --gap-fill: %s",
+                               Arg->getValue());
+    Config.GapFill = *Val;
+  }
+  if (auto Arg = InputArgs.getLastArg(OBJCOPY_pad_to)) {
+    ErrorOr<uint64_t> Addr = getAsInteger<uint64_t>(Arg->getValue());
+    if (!Addr)
+      return createStringError(Addr.getError(), "bad address for --pad-to: %s",
+                               Arg->getValue());
+    Config.PadTo = *Addr;
+  }
   for (auto Arg : InputArgs.filtered(OBJCOPY_redefine_symbol)) {
     if (!StringRef(Arg->getValue()).contains('='))
       return createStringError(errc::invalid_argument,
                                "bad format for --redefine-sym");
     auto Old2New = StringRef(Arg->getValue()).split('=');
     if (!Config.SymbolsToRename.insert(Old2New).second)
       return createStringError(errc::invalid_argument,
                                "multiple redefinition of symbol '%s'",

llvm/tools/llvm-objcopy/ELF/ELFObjcopy.cpp

replaceDebugSections(
         [&Obj](const SectionBase *S) {
           auto CS = cast<CompressedSection>(S);
           return &Obj.addSection<DecompressedSection>(*CS);
         });
 
   return Obj.removeSections(Config.AllowBrokenLinks, RemovePred);
 }
 
+static Error padSections(const CopyConfig &Config, Object &Obj) {
+  SmallVector<SectionBase *, 30> LoadableSections;
+  for (SectionBase &Sec : Obj.sections()) {
+    if ((Sec.Flags & SectionFlag::SecLoad) && (Sec.Type != SHT_NOBITS))
+      LoadableSections.push_back(&Sec);
+  }
+
+  if (LoadableSections.empty())
+    return Error::success();
+
+  llvm::stable_sort(LoadableSections,
+                    [](const SectionBase *LHS, const SectionBase *RHS) {
+                      if (LHS->Addr < RHS->Addr)
+                        return true;
+                      if (LHS->Addr > RHS->Addr)
+                        return false;
+                      return (LHS->Size < RHS->Size);
+                    });
+
+  std::map<SectionBase *, uint64_t> SectionGapMap;
+  // Default filled value for '--pad-to' option.
+  uint8_t Value = 0;
+
+  // Fill the gaps if the section's not in any segement. Otherwise just record
+  // the gaps.
+  auto setSectionGaps = [&SectionGapMap](SectionBase *Sec, uint32_t Value,
+                                         uint64_t GapsSize) {
+    if (Sec->ParentSegment)
+      SectionGapMap[Sec] = GapsSize;
+    else {
+      Sec->Size += GapsSize;
+      uint8_t *N = new uint8_t[Sec->Size];
+      llvm::copy(Sec->OriginalData, &N[0]);
+      memset(N + Sec->OriginalData.size(), Value, GapsSize);
+      Sec->OriginalData = makeArrayRef<uint8_t>(N, Sec->Size);
+    }
+  };
+
+  if (Config.GapFill) {
+    Value = Config.GapFill.getValue();
+    for (SmallVectorImpl<SectionBase *>::const_iterator
+             I = LoadableSections.begin(),
+             E = LoadableSections.end() - 1;
+         I != E; ++I) {
+      if ((*I)->Size == 0)
+        continue;
+      uint64_t GapBegin = (*I)->Addr + (*I)->Size;
+      uint64_t GapEnd = (*(I + 1))->Addr;
+      if (GapEnd <= GapBegin)
+        continue;
+      setSectionGaps(*I, Value, GapEnd - GapBegin);
+    }
+  }
+
+  if (Config.PadTo) {
+    SectionBase *LastSec = *(LoadableSections.end() - 1);
+    uint64_t SecEndAddr = LastSec->Addr + LastSec->Size;
+    if (LastSec->Size && SecEndAddr < Config.PadTo.getValue())
+      setSectionGaps(LastSec, Value, Config.PadTo.getValue() - SecEndAddr);
+  }
+
+  // Populate section and segment content.
+  // First, resize the section and its containing segment if needed.
+  std::map<Segment *, uint8_t *> NewSegments;
+  for (auto &It : SectionGapMap) {
+    SectionBase *Sec = It.first;
+    uint64_t GapsSize = It.second;
+    // Two adjacent sections might overlap in the same segment. Adjust its
+    // layout in next step.
+    Sec->Size += GapsSize;
+
+    auto SecParent = Sec->ParentSegment;
+    assert(SecParent != nullptr);
+    for (auto &Seg : Obj.segments()) {
+      auto SegmentEndAddr = Seg.VAddr + Seg.Contents.size();
+      if (Sec->Addr >= Seg.VAddr && Sec->Addr < SegmentEndAddr &&
+          (Sec->Addr + Sec->Size) > SegmentEndAddr) {
+        Seg.FileSize += GapsSize;
+        Seg.MemSize += GapsSize;
+
+        if (!SecParent->ParentSegment && SecParent == &Seg) {
+          if (NewSegments.find(SecParent) == NewSegments.end()) {
+            NewSegments[SecParent] = new uint8_t[SecParent->FileSize];
+            llvm::copy(SecParent->getContents(), NewSegments[SecParent]);
+          }
+        }
+      }
+    }
+  }
+
+  if (NewSegments.empty())
+    return Error::success();
+
+  // Second, adjust segments and sections layouts after the resizing.
+  auto PreSec = *(LoadableSections.end() - 1);
+  auto Index = PreSec->Index;
+  auto PreSecEnd = PreSec->OriginalOffset + PreSec->Size;
+  Index++;
+  Twine Msg;
+  for (auto Size = Obj.sections().size(); Index < Size; ++Index) {
+    auto CurSec = Obj.sections().getSection(Index, Msg);
+    if (CurSec->OriginalOffset < PreSecEnd) {
+      CurSec->OriginalOffset = PreSecEnd;
+      PreSecEnd = CurSec->OriginalOffset + CurSec->Size;
+    }
+  }
+
+  // Third, set the new segment's content.
+  for (auto &It : SectionGapMap) {
+    SectionBase *Sec = It.first;
+    uint64_t GapsSize = It.second;
+    auto SecParent = It.first->ParentSegment;
+    const auto Iter = NewSegments.find(SecParent);
+    if (Iter != NewSegments.end()) {
+      uint64_t Offset = Sec->OriginalOffset - SecParent->OriginalOffset;
+      std::memset(Iter->second + Offset + Sec->OriginalData.size(), Value,
+                  GapsSize);
+    }
+  }
+
+  for (auto &It : NewSegments)
+    It.first->Contents = makeArrayRef<uint8_t>(It.second, It.first->FileSize);
+
+  // Fourth, set the new segment's child content.
+  for (auto &Seg : Obj.segments()) {
+    auto SegParent = Seg.ParentSegment;
+    const auto Iter = NewSegments.find(SegParent);
+    if (Iter != NewSegments.end()) {
+      uint64_t Offset = Seg.OriginalOffset - SegParent->OriginalOffset;
+      Seg.Contents = makeArrayRef<uint8_t>(Iter->second + Offset, Seg.FileSize);
+    }
+  }
+
+  // Last step, set the section content.
+  for (auto &Sec : Obj.sections()) {
+    auto SecParent = Sec.ParentSegment;
+    const auto Iter = NewSegments.find(SecParent);
+    if (Iter != NewSegments.end() && Sec.Type != SHT_NOBITS) {
+      uint64_t Offset =
+          Sec.OriginalOffset - SecParent->OriginalOffset + SecParent->Offset;
+      Sec.OriginalData = makeArrayRef<uint8_t>(Iter->second + Offset, Sec.Size);
+    }
+  }
+
+  return Error::success();
+}
+
 // This function handles the high level operations of GNU objcopy including
 // handling command line options. It's important to outline certain properties
 // we expect to hold of the command line operations. Any operation that "keeps"
 // should keep regardless of a remove. Additionally any removal should respect
 // any previous removals. Lastly whether or not something is removed shouldn't
 // depend a) on the order the options occur in or b) on some opaque priority
 // system. The only priority is that keeps/copies overrule removes.
 static Error handleArgs(const CopyConfig &Config, Object &Obj,
static Error handleArgs(const CopyConfig &Config, Object &Obj,
   for (const NewSymbolInfo &SI : Config.SymbolsToAdd) {
     SectionBase *Sec = Obj.findSection(SI.SectionName);
     uint64_t Value = Sec ? Sec->Addr + SI.Value : SI.Value;
     Obj.SymbolTable->addSymbol(
         SI.SymbolName, SI.Bind, SI.Type, Sec, Value, SI.Visibility,
         Sec ? (uint16_t)SYMBOL_SIMPLE_INDEX : (uint16_t)SHN_ABS, 0);
   }
 
+  if ((Config.GapFill || Config.PadTo) && Obj.sections().size()) {
+    if (Error E = padSections(Config, Obj))
+      return E;
+  }
+
   if (Config.EntryExpr)
     Obj.Entry = Config.EntryExpr(Obj.Entry);
   return Error::success();
 }
 
 static Error writeOutput(const CopyConfig &Config, Object &Obj, Buffer &Out,
                          ElfType OutputElfType) {
   std::unique_ptr<Writer> Writer =

llvm/tools/llvm-objcopy/ObjcopyOpts.td

 
 defm add_symbol
     : Eq<"add-symbol", "Add new symbol <name> to .symtab. Accepted flags: "
          "global, local, weak, default, hidden, protected, file, section, object, "
          "function, indirect-function. Accepted but ignored for "
          "compatibility: debug, constructor, warning, indirect, synthetic, "
          "unique-object, before.">,
       MetaVarName<"name=[section:]value[,flags]">;
+
+defm gap_fill
+    : Eq<"gap-fill",
+      "Fill gaps between two loadable sections with <val>.">,
+      MetaVarName<"val">;
+
+defm pad_to
+    : Eq<"pad-to",
+      "Pad the last loadable section up to <addr> with the value specified by --gap-fill if present or zero by default.">,
+      MetaVarName<"addr">;