For sections with different virtual and physical addresses, alignment and
placement in the output binary should be based on the physical address.
Ran into this problem with a bare metal ARM project where llvm-objcopy added a
lot of zero-padding before the .data section that had differing addresses. GNU
objcopy did not add the padding, and after this fix, neither does llvm-objcopy.
Update a test case so a section has different physical and virtual addresses.
Fixes B35708
Authored By: Owen Shaw (owenpshaw)
Differential Revision: https://reviews.llvm.org/D41619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323144 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds support in llvm-objcopy for GNU objcopy's --localize-hidden
option. This option changes every hidden or internal symbol into a local symbol.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321884 91177308-0d34-0410-b5e6-96231b3b80d8
I have no clue how this was missed when symbol table support was added. This
change ensures that the visibility of symbols is preserved by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321681 91177308-0d34-0410-b5e6-96231b3b80d8
The original -O binary implementation just copied segment data from the
object and dumped it into a file. This doesn't take into account any
operations performed on objects such as section removal. GNU objcopy has
some specific behavior that we'd also like to respect. For instance
using -O binary and -j <some_section> will dump <some_section> to a
file. This change implements GNU objcopy style -O binary to as close of
an approximation as I can determine.
Differential Revision: https://reviews.llvm.org/D39713
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318324 91177308-0d34-0410-b5e6-96231b3b80d8
Just aligning segment offsets to segment alignment is incorrect and also
wastes more space than is needed. The requirement is that p_offset ==
p_addr modulo p_align *not* that p_offset == 0 modulo p_align. Generally
speaking we've been using p_addr == 0 modulo p_align. In fact yaml2obj
can't even produce a valid situation which causes llvm-objcopy to
produce incorrect results because alignment and offset were both
inherited from the sections the program header covers. This change fixes
this bad behavior in llvm-objcopy.
Differential Revision: https://reviews.llvm.org/D39132
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317284 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315536 91177308-0d34-0410-b5e6-96231b3b80d8
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315530 91177308-0d34-0410-b5e6-96231b3b80d8
ubsan caught an issue I made where I was converting a null pointer to a
reference.
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315484 91177308-0d34-0410-b5e6-96231b3b80d8
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315412 91177308-0d34-0410-b5e6-96231b3b80d8
If a Section had Type SHT_STRTAB (which could happen if you had a
.dynstr section) it was possible to cast Section to StringTableSection
and get away with any operation that was supported by SectionBase
without it being noticed. This change makes this bug easier to notice
and fixes it where it occurred. It also made me realize that there was
some duplication of efforts in the loop that calls ::initialize. These
issues are all fixed by this change.
Differential Revision: https://reviews.llvm.org/D38329
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315372 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds support for removing sections using the -R field (as
GNU objcopy does as well). This change should let us add many helpful
tests and is a proper stepping stone for adding more general kinds of
stripping.
Differential Revision: https://reviews.llvm.org/D38260
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315346 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow a few massive errors slipped though the cracks of testing.
1. The code in Segment::finalize was left over from the old layout
algorithm. In certain situations this would cause very strange issues
with segment layout. For instance in the shift-segments.test case it
would cause the second segment to have the same offset as the first.
2. In debugging this I discovered another issue. Namely section alignment
was not being computed based on Section->Align but instead
Section->Offset which is bizarre and makes no sense. I have no clue how
it worked in the first place. This issue is also fixed
3. Fixing #2 exposed a bug where things were not being written past the end
of the file that technically should have been. This was because in
certain cases (like overlapping-segments) the end of the file wouldn't
always be bumped if the offset could be chosen relative to an existing
segment that already had it's offset chosen. For fully nested segments
this is fine but for overlapping segments this leaves the end of the
file short. So I changed how the offset is bumped when looping though
segments.
Differential Revision: https://reviews.llvm.org/D38436
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314918 91177308-0d34-0410-b5e6-96231b3b80d8
This change refactors some of the code to allow for some code
deduplication in later diffs as well as just to make adding a new
section type more self contained to the class itself. The idea for this
was first mentioned by James in D 37915 and will be used in that change
as recommended.
This change follows changes for dynamic sections but precedes support
for dynamic relocations.
Differential Revision: https://reviews.llvm.org/D38008
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314148 91177308-0d34-0410-b5e6-96231b3b80d8
I overzealously landed this before I was sure that another change
wouldn't break the build that this change depends on.
This change adds support for sections involved in dynamic loading such
as SHT_DYNAMIC, SHT_DYNSYM, and allocated string tables.
The two added binaries used for tests can be downloaded here and here
Differential Revision: https://reviews.llvm.org/D36560
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313767 91177308-0d34-0410-b5e6-96231b3b80d8
I didn't initialize a pointer to be nullptr that I needed to.
This change adds support for nested and even overlapping segments. This means
that PT_PHDR, PT_GNU_RELRO, PT_TLS, and PT_DYNAMIC can be supported properly.
Differential Revision: https://reviews.llvm.org/D36558
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313682 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on llvm-commits it was decided it would be best to check
e_machine before declaring that a reserved section index is valid. The
only special e_machine value that matters here is EM_HEXAGON. This
change adds a special check for EM_HEXAGON.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D37767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313114 91177308-0d34-0410-b5e6-96231b3b80d8
As is indexes above SHN_LORESERVE will not be handled correctly because
they'll be treated as indexes of sections rather than special values
that should just be copied. This change adds support to copy them
though.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D37393
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312756 91177308-0d34-0410-b5e6-96231b3b80d8
The current file layout algorithm in llvm-objcopy is simple but
difficult to reason about. It also makes it very complicated to support
nested segments and to support segments that have offsets that come
before a point after the program headers. To support these cases and
simplify one of the most critical parts llvm-objcopy I rewrote the
layout algorithm. Laying out segments first solves most of the issues
encountered by the previous algorithm.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D36494
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311825 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes LLD will produce a PT_LOAD segment that only covers the
headers (and covers no sections). GNU objcopy does not output the
segment contents for these sections. In particular this is an issue in
building magenta because the final link step for the kernel would
produce just such a PT_LOAD segment. This change is to support this case
and to match what GNU objcopy does in this case.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D36196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310149 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds the "-O binary" flag which directs llvm-objcopy to
output the object file to the same format as GNU objcopy does when given
the flag "-O binary". This was done by splitting the Object class into
two subclasses ObjectELF and ObjectBianry which each output a different
format but relay on the same code to read in the Object in Object.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D34480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310127 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds the "-O binary" flag which directs llvm-objcopy to
output the object file to the same format as GNU objcopy does when given
the flag "-O binary". This was done by splitting the Object class into
two subclasses ObjectELF and ObjectBianry which each output a different
format but relay on the same code to read in the Object in Object.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D34480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310018 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds the "-O binary" flag which directs llvm-objcopy to
output the object file to the same format as GNU objcopy does when given
the flag "-O binary". This was done by splitting the Object class into
two subclasses ObjectELF and ObjectBianry which each output a different
format but relay on the same code to read in the Object in Object.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D34480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309768 91177308-0d34-0410-b5e6-96231b3b80d8
The change seems to be failing on bots which are using gcc and bfd.ld
as a host compiler and linker.
This reverts commit r309658.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309660 91177308-0d34-0410-b5e6-96231b3b80d8
This change adds the "-O binary" flag which directs llvm-objcopy to
output the object file to the same format as GNU objcopy does when given
the flag "-O binary". This was done by splitting the Object class into
two subclasses ObjectELF and ObjectBianry which each output a different
format but relay on the same code to read in the Object in Object.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D34480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309658 91177308-0d34-0410-b5e6-96231b3b80d8
