Per discussion on the generic-abi mailing list:
https://groups.google.com/forum/#!topic/generic-abi/MPr8TVtnVn4
An object file manipulation tool must either write out a symbol
table with the same number of entries as the original symbol table
and in the same order, or if this is impossible, refuse to operate
on the object file if it has unrecognized sections that are linked
to the symtab section. However, existing tools (namely GNU strip,
GNU objcopy and ld.{bfd,gold,lld} -r) do not comply with this at
present: they change symbol table indexes and set sh_link to 0 on
the unrecognized symtab-linked sections.
We intend to use the latter as a (temporary) signal that a tool has
operated on a proposed new symtab-linked section and invalidated the
symbol table indexes. However, llvm-objcopy currently keeps sh_link
pointing to the new symtab section. This patch changes llvm-objcopy
to set sh_link to 0 to match the behaviour of the other tools.
Differential Revision: https://reviews.llvm.org/D47404
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333581 91177308-0d34-0410-b5e6-96231b3b80d8
This is a small follow-up to the revisions r333117 and r331663.
1. Avoid the name conflicts of the generated variables for prefixes.
2. Apply clang-format -i -style=llvm to llvm-objcopy.cpp once again.
3. Add a test for the flag with double dash.
Test plan: make check-all
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@333120 91177308-0d34-0410-b5e6-96231b3b80d8
This option just keeps being a problem and really needs to be implemented
in some fashion. Implementing it properly requires some kind of
"replaceSectionReference" method because all the existing links need to be
maintained. The desired behavior is just for allocated sections to become
NOBITS but actually implementing that is rather tricky due to the current
design of llvm-objcopy. However converting allocated sections to NOBITS is
just an optimization and not something debuggers need. Debuggers can debug
a stripped executable and take an unstripped executable for that stripped
executable as input. Additionally allocated sections account for a very
small part of debug binaries so this optimization is quite small. I propose
that for the time being we implement this as a NOP so that people can use
llvm-objcopy where they need to, just in a sub-optimal way.
This option has already blocked a lot of people and its currently blocking me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332396 91177308-0d34-0410-b5e6-96231b3b80d8
Verify that the input binary is not getting modified
and add an invocation which uses -remove-section instead of -R.
Test plan: make check-all
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332078 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-strip is supposed to be a drop-in replacement for binutils strip.
To start the ball rolling this diff adds the initial bits for llvm-strip,
more features will be added incrementally over time.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D46407
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@331663 91177308-0d34-0410-b5e6-96231b3b80d8
Add explicit dependency on ObjcopyTableGen
and rerun the tests on Windows.
I will double-check the build bots
and revert this commit if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330685 91177308-0d34-0410-b5e6-96231b3b80d8
This diff fixes sh_link for various types of sections
(i.e. for SHT_ARM_EXIDX, SHT_HASH). In particular, this change enables us
to use llvm-objcopy with clang -gsplit-dwarf for the target android-arm.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D45851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330478 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen seems to work differently on windows. I'll need to revert this
This reverts commit 7a153ddea067b24da59f6a66c733d79205969501.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329867 91177308-0d34-0410-b5e6-96231b3b80d8
This diff adds support for SHT_GROUP sections to llvm-objcopy.
Some sections are interrelated and comprise a group.
For example, a definition of an inline function might require,
in addition to the section containing its instructions,
a read-only data section containing literals referenced inside the function.
A section of the type SHT_GROUP contains the indices of the group members,
therefore, it needs to be updated whenever the indices change.
Similarly, the fields sh_link, sh_info should be recalculated as well.
[Resubmit r328012 with the proper handling of endianness]
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D43996
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328143 91177308-0d34-0410-b5e6-96231b3b80d8
This diff adds support for SHT_GROUP sections to llvm-objcopy.
Some sections are interrelated and comprise a group.
For example, a definition of an inline function might require,
in addition to the section containing its instructions,
a read-only data section containing literals referenced inside the function.
A section of the type SHT_GROUP contains the indices of the group members,
therefore, it needs to be updated whenever the indices change.
Similarly, the fields sh_link, sh_info should be recalculated as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D43996
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@328012 91177308-0d34-0410-b5e6-96231b3b80d8
Not all build bots have unzip which I used in a test.
This reverts commit 0b1f26d39ea42dd3716b525fbc8c78d8c7bb4479.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326941 91177308-0d34-0410-b5e6-96231b3b80d8
Because of -ffunction-sections (and maybe other use cases I'm not aware of?) it
can occur that we need more than 0xfeff sections but ELF dosn't support that
many sections. To solve this problem SHN_XINDEX exists and with it come a whole
host of changes for section indexes everywhere. This change adds support for
those cases which should allow llvm-objcopy to copy binaries that have an
arbitrary number of sections.
Differential Revision: https://reviews.llvm.org/D42516
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326940 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current implementation was writing the file name without the extension
whereas GNU objcopy writes the full filename. With this change GDB will now
load the .debug file instead of silently ignoring it.
Reviewers: jakehehrlich, jhenderson
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43474
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325528 91177308-0d34-0410-b5e6-96231b3b80d8
Some ELF files produced by lld may have zero-size segment placeholders as shown
below. Since GNU_STACK Offset is 0, the current code makes it the lowest used
offset, and relocates all the segments over the ELF header. The resulting
binary is total garbage.
This change fixes how llvm-objcopy handles PT_PHDR properlly by treating ELF
headers and the program header table as segments to allow the layout algorithm
decide where those should go.
Author: vit9696
Differential Revision: https://reviews.llvm.org/D42872
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325189 91177308-0d34-0410-b5e6-96231b3b80d8
If the output file is not specified make the modifications in-place
(like binutils objcopy does). In particular, this fixes
the behavior of Clang -gsplit-dwarf (if Clang is configured to use llvm-objcopy),
previously it was creating .dwo files, but still leaving *dwo* sections in
the original binary.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42873
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@324783 91177308-0d34-0410-b5e6-96231b3b80d8
While writing code for input and output formats in llvm-objcopy it became
apparent that there was a code health problem. This change attempts to solve
that problem by refactoring the code to use Reader and Writer objects that can
read in different objects in different formats, convert them to a single shared
internal representation, and then write them to any other representation.
New classes:
Reader: the base class used to construct instances of the internal
representation
Writer: the base class used to write out instances of the internal
representation
ELFBuilder: a helper class for ELFWriter that takes an ELFFile and converts it
to a Object
SectionVisitor: it became necessary to remove writeSection from SectionBase
because, under the new Reader/Writer scheme, it's possible to convert between
ELF Types such as ELF32LE and ELF32BE. This isn't possible with writeSection
because it (dynamically) depends on the underlying section type *and*
(statically) depends on the ELF type. Bad things would happen if the underlying
sections for ELF32LE were used for writing to ELF64BE. To avoid this code smell
(which would have compiled, run, and output some nonsesnse) I decoupled writing
of sections from a class.
SectionWriter: This is just the ELFT templated implementation of
SectionVisitor. Many classes now have this class as a friend so that the
writing methods in this class can write out private data.
ELFWriter: This is the Writer that outputs to ELF
BinaryWriter: This is the Writer that outputs to Binary
ElfType: Because the ELF Type is not a part of the Object anymore we need a way
to construct the correct default Writer based on properties of the Reader. This
enum just keeps track of the ELF type of the input so it can be used as the
default output type as well.
Object has correspondingly undergone some serious changes as well. It now has
more generic methods for building and manipulating ELF binaries. This interface
makes ELFBuilder easy enough to use and will make the BinaryReader/Builder easy
to create as well. Most changes in this diff are cosmetic and deal with the
fact that a method has been moved from one class to another or a change from a
pointer to a reference. Almost no changes should result in a functional
difference (this is after all a refactor). One minor functional change was made
and the result can be seen in remove-shstrtab-error.test. The fact that it
fails hasn't changed but the error message has changed because that failure is
detected at a later point in the code now (because WriteSectionHeaders is a
property of the ElfWriter *not* a property of the Object). I'd say roughly
80-90% of this code is cosmetically different, 10-19% is different but
functionally the same, and 1-5% is functionally different despite not causing a
change in tests.
Differential Revision: https://reviews.llvm.org/D42222
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@323480 91177308-0d34-0410-b5e6-96231b3b80d8
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
