This patch fixes https://bugs.llvm.org/show_bug.cgi?id=41293 and
https://bugs.llvm.org/show_bug.cgi?id=41045. llvm-objcopy assumed that
it could always read a section header string table. This isn't the case
when the sections were previously all stripped, and the e_shstrndx field
was set to 0. This patch fixes this. It also fixes a double space in an
error message relating to this issue, and prevents llvm-objcopy from
adding extra space for non-existent section headers, meaning that
--strip-sections on the output of a previous --strip-sections run
produces identical output, simplifying the test.
Reviewed by: rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D59989
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357475 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
BTW, STLExtras.h provides llvm::size() which is similar to std::size()
for random access iterators. However, if we prefer qualified
llvm::size(), the member function .size() will be more convenient.
Reviewers: jhenderson, jakehehrlich, rupprecht, grimar, alexshap, espindola
Reviewed By: grimar
Subscribers: emaste, arichardson, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60028
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@357347 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-objcopy previously knew nothing about data in segments that wasn't
covered by section headers, meaning that it wrote zeroes instead of what
was there. As it is possible for this data to be useful to the loader,
this patch causes llvm-objcopy to start preserving this data. Data in
sections that are explicitly removed continues to be written as zeroes.
This fixes https://bugs.llvm.org/show_bug.cgi?id=41005.
Reviewed by: jakehehrlich, rupprecht
Differential Revision: https://reviews.llvm.org/D59483
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356919 91177308-0d34-0410-b5e6-96231b3b80d8
Fix: r356853 + set AddressAlign to 4 in
Inputs/compress-debug-sections.yaml for the new group section introduced.
Original commit message:
Currently, llvm-objcopy incorrectly handles compression and decompression of the
sections from COMDAT groups, because we do not implement the
replaceSectionReferences for this type of the sections.
The patch does that.
Differential revision: https://reviews.llvm.org/D59638
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356856 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the reason of ubsan failure (UB detected)
happened after landing the D59638 (I had to revert it).
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/11760/steps/check-llvm%20ubsan/logs/stdio)
Problem is the following. Our implementation of GroupSection assumes that
its address is 4 bytes aligned when writes it:
template <class ELFT>
void ELFSectionWriter<ELFT>::visit(const GroupSection &Sec) {
ELF::Elf32_Word *Buf =
reinterpret_cast<ELF::Elf32_Word *>(Out.getBufferStart() + Sec.Offset);
...
But the test case for D59638 did not set AddressAlign in YAML. So address was
not 4 bytes aligned since Sec.Offset was odd. That triggered the issue.
This patch teaches llvm-objcopy to report an error for such sections (which should
not met in reality), what is better than having UB.
Differential revision: https://reviews.llvm.org/D59695
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356853 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, llvm-objcopy incorrectly handles compression and decompression of the
sections from COMDAT groups, because we do not implement the
replaceSectionReferences for this type of the sections.
The patch does that.
Differential revision: https://reviews.llvm.org/D59638
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356738 91177308-0d34-0410-b5e6-96231b3b80d8
GNU objcopy can support output formats like elf32-i386-freebsd and
elf64-x86-64-freebsd. The only difference from their regular non-freebsd
counterparts that I have observed is that the freebsd versions set the
OS/ABI field to ELFOSABI_FREEBSD. This patch sets the OS/ABI field
according based on the format whenever --output-format is specified.
Reviewed by: rupprecht, grimar
Differential Revision: https://reviews.llvm.org/D59645
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356737 91177308-0d34-0410-b5e6-96231b3b80d8
This change makes linking into .build-id atomic and safe to use.
Some users under particular workflows are reporting that this races
more than half the time under particular conditions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356404 91177308-0d34-0410-b5e6-96231b3b80d8
For ELF, we accept but ignore --only-keep-debug. Do the same for llvm-strip.
COFF does implement this, so update the test that it is supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356207 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes llvm-objcopy's behaviour to not strip sections that
are in segments, if they otherwise would be due to a stripping operation
(--strip-all, --strip-sections, --strip-non-alloc). This preserves the
segment contents. It does not change the behaviour of --strip-all-gnu
(although we could choose to do so), because GNU objcopy's behaviour in
this case seems to be to strip the section, nor does it prevent removing
of sections in segments with --remove-section (if a user REALLY wants to
remove a section, we should probably let them, although I could be
persuaded that warning might be appropriate). Tests have been added to
show this latter behaviour.
This fixes https://bugs.llvm.org/show_bug.cgi?id=41006.
Reviewed by: grimar, rupprecht, jakehehrlich
Differential Revision: https://reviews.llvm.org/D59293
This is a reland of r356129, attempting to fix greendragon failures
due to a suspected compatibility issue with od on the greendragon bots
versus other versions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356136 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes llvm-objcopy's behaviour to not strip sections that
are in segments, if they otherwise would be due to a stripping operation
(--strip-all, --strip-sections, --strip-non-alloc). This preserves the
segment contents. It does not change the behaviour of --strip-all-gnu
(although we could choose to do so), because GNU objcopy's behaviour in
this case seems to be to strip the section, nor does it prevent removing
of sections in segments with --remove-section (if a user REALLY wants to
remove a section, we should probably let them, although I could be
persuaded that warning might be appropriate). Tests have been added to
show this latter behaviour.
This fixes https://bugs.llvm.org/show_bug.cgi?id=41006.
Reviewed by: grimar, rupprecht, jakehehrlich
Differential Revision: https://reviews.llvm.org/D59293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356129 91177308-0d34-0410-b5e6-96231b3b80d8
error() was previously cleaned up from CopyConfig, but new uses were introduced.
This also tweaks the error message for --add-symbol to report all invalid flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@356105 91177308-0d34-0410-b5e6-96231b3b80d8
When --compress-debug-sections is given,
llvm-objcopy removes the uncompressed sections and adds compressed to the section list.
This makes all the pointers to old sections to be outdated.
Currently, code already has logic for replacing the target sections of the relocation
sections. But we also have to update the relocations by themselves.
This fixes https://bugs.llvm.org/show_bug.cgi?id=40885.
Differential revision: https://reviews.llvm.org/D58960
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355821 91177308-0d34-0410-b5e6-96231b3b80d8
We should create CompressedSection only if the section has SHF_COMPRESSED flag
or it's name starts from '.zdebug'.
Currently, we create it if section's data starts from ZLIB signature.
Differential revision: https://reviews.llvm.org/D59018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355501 91177308-0d34-0410-b5e6-96231b3b80d8
When --compress-debug-sections is given, llvm-objcopy do not compress
sections that have "ZLIB" header in data. Normally this signature is used
in zlib-gnu compression format. But if zlib-gnu used then the name of the compressed
section should start from .z* (e.g .zdebug_info). If it does not, then it is not
a zlib-gnu format and section should be treated as a normal uncompressed section.
Differential revision: https://reviews.llvm.org/D58908
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@355399 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This removes calls to `error()`/`reportError()` in the main driver (llvm-objcopy.cpp) as well as the associated argv-parsing (CopyConfig.cpp). `logAllUnhandledErrors()` is now the main way to print errors.
There are still a few uses from within the per-arch drivers, so we can't delete them yet... but almost!
Reviewers: jhenderson, alexshap, espindola
Reviewed By: jhenderson
Subscribers: emaste, arichardson, jakehehrlich, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58316
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354600 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Removing a large number of sections from a file with a lot of symbols can have abysmal (i.e. O(n^2)) performance, e.g. when running `--only-section` to extract one section out of a large file.
This comes from iterating over all symbols in the symbol table each time we remove a section, to remove references to the section we just removed.
Instead, do just one pass of symbol removal by passing a hash set of all the sections we'd like to remove references to.
This fixes a regression when running llvm-objcopy -j <one section> on an object file with many sections and symbols -- on my machine, running `objcopy -j .keep_me huge-input.o /tmp/foo.o` takes .3s with GNU objcopy, 1.3s with an updated llvm-objcopy, and 7+ minutes with llvm-objcopy prior to this patch.
Reviewers: MaskRay, jhenderson, jakehehrlich, alexshap, espindola
Reviewed By: MaskRay, jhenderson
Subscribers: echristo, emaste, arichardson, mgrang, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58296
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@354597 91177308-0d34-0410-b5e6-96231b3b80d8
