getRawNumberOfSymbols() assumes that a symbol table exists, which isn't
always guaranteed, while getNumberOfSymbols() handles and tolerates objects
without a symbol table. When there is a symbol table, both methods return
the same value.
Also add a test to ensure we don't regress in this regard. The test
generates a basic COFF object with symbols and overrides the symbol table
pointer with zeros to craft the input required to verify llvm-objcopy works
as expected in this scenario.
This used %zu to print a uint64_t type. z is for size_t so on 32 bit
we tried to treat it as a 32 bit number.
Use PRIu64 instead to print as 64 bit everywhere.
a1b4e13cff2a792571927ee1fc6eebb05e40fae9 updated this to use
the target= syntax.
However the triple for our Arm bots is usually like:
armv8l-unknown-linux-gnueabihf
With "eabihf" on the end. I assume before we just checked for
"linux-gnu" being in the triple at all but now it is a proper
regex match.
Add .* on the end to account for the ABI tag on the end.
Implicit cast between char* and StringRef when writing sections.
Reproduce:
```
$> llvm-objcopy --dump-section=name=name.data out.wasm
$> llvm-objcopy --remove-section=name out.wasm out_no_name.wasm
$> llvm-objcopy --add-section=name=name.data out_no_name.wasm out_new_name.wasm
# With wasm-objdump -h we can see that the name section is not totally copied in the new wasm file (if it actually contain empty bytes)
```
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D139210
If we don't want to set PointerToRawData, for an empty section,
we do must set it to zero explicitly. Some object file generators
do set it to zero for empty sections, while others set a nonzero
value pointing at the end of the previous section.
If the value was nonzero on input, we need to update it - either
setting it to zero, or to a valid offset in the output file (not
out of bounds)
This fixes https://github.com/mstorsjo/llvm-mingw/issues/313.
Testing this is tricky, because we can't use yaml2obj, since that
doesn't produce object files with nonzero PointerToRawData for
empty sections. We can use llvm-mc to assemble a small file
(assuming that LLVM's MC layer keeps this behaviour), or bundle
a small binary object file. I opted for using llvm-mc for now here
(with a test that it actually does keep this property), but I don't
mind changing it to a canned object file to make the test less brittle.
Differential Revision: https://reviews.llvm.org/D138783
The exports trie and the chained fixups where in the opposite order, and
function starts happenned before them, instead of after them.
Restore the correct order and rewrite the code to make it easier to move
around in the future if needed by reusing the `Offset` variable and
keeping both the `StartOf...` and the size of each piece together.
This was found out while trying to use the system strip in a binary
already stripped by LLVM and receiving errors around chained fixups when
we enabled those in the linker.
Reviewed By: alexander-shaposhnikov
Differential Revision: https://reviews.llvm.org/D133974
These weren't running anywhere because of bad specifications.
One test has bit-rotted and had to be XFAILed, the rest are okay.
Differential Revision: https://reviews.llvm.org/D136612
When zlib is disabled at build time, the diagnostic `LLVM was not compiled with
LLVM_ENABLE_ZLIB: cannot decompress` for --decompress-debug-sections may be
inaccurate: if zstd is enabled, we should still support zstd decompression.
It's not useful to test zlib and zstd. Just remove the diagnostic and add a new
one before `compression::decompress`.
This fixes compress-debug-sections-zstd.test
Reviewed By: mariusz-sikora-at-amd, jhenderson, phosek
Differential Revision: https://reviews.llvm.org/D135744
For an ELFCLASS32 object, a compressed section due to --compress-debug-sections={zlib,zstd} has a
tail padding of 12 zero bytes. zlib happily allows this while zstd is rigid and
reports `error: '{{.*}}': failed to decompress section '.debug_foo': Src size is incorrect`.
Cole Kissane reported the problem.
Reviewed By: jhenderson, phosek
Differential Revision: https://reviews.llvm.org/D134385
This reverts commit 19dc3cff0f771bb8933136ef68e782553e920d04.
This reverts commit 5b19a1f8e88da9ec92b995bfee90043795c2c252.
This reverts commit 9397648ac8ad192f7e6e6a8e6894c27bf7e024e9.
This reverts commit 10842b44759f987777b08e7714ef77da2526473a.
Breaks the GCC build, as reported here:
https://reviews.llvm.org/D130506#3776415
This adds the other potential bitcode sections that can exist and should
be stripped with `-r` from `llvm-bitcode-strip`.
Differential Revision: https://reviews.llvm.org/D132267
This reverts commit c26dc2904b95b3685d883e760e84046ea6c33d7f.
The new Zstd dispatch has an ongoing design discussion related to https://reviews.llvm.org/D130516#3688123 .
Revert for now before it is resolved.
The request is mentioned on D129053. I feel that having this functionality is
mildly useful (not strong).
* Rename .ctors to .init_array and change sh_type to SHT_INIT_ARRAY (GNU objcopy
detects the special name but we don't).
* Craft tests for a new SHT_LLVM_* extension
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D129337
* GNU objcopy supports --set-section-flags src=... --rename-section src=tst and --set-section-flags runs first.
* GNU objcopy processes --update-section before --rename-section.
To match the two behaviors, postpone --rename-section and allow its use together
with --set-section-flags.
As a side effect, --rename-section=.foo1=.foo2 --add-section=.foo1=/dev/null
leads to .foo2 while GNU objcopy surprisingly produces .foo1 (so
--set-section-flags --add-section --rename-section do not form a total order).
I think the deviation is fine as a total order makes more sense.
Rename set-section-flags-and-rename.test to
set-section-attr-and-rename.test and additionally test --set-section-alignment
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D129336
For a SHT_NOBITS section like .bss, its sh_offset is typically not
aligned by sh_addralign. If it is converted to SHT_PROGBITS by
`--set-section-flags .bss=alloc,contents`, we should conceptually align
it when computing the output size for -O binary. Otherwise the output
size may be smaller than GNU objcopy produced output.
* binary-no-paddr.test has a case with non-sensical p_paddr=1 which has
a changed behavior. Update it.
Close https://github.com/llvm/llvm-project/issues/55246
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D128961
clang 14 removed -gz=zlib-gnu support and ld.lld removed linker input support
for zlib-gnu in D126793. Now let's remove zlib-gnu from llvm-objcopy.
* .zdebug* sections are no longer recognized as debug sections. --strip* don't remove them.
They are copied like other opaque sections
* --decompress-debug-sections does not uncompress .zdebug* sections
* --compress-debug-sections=zlib-gnu is not supported
It is very rare but in case a user has object files using .zdebug . They can use
llvm-objcopy<15 or GNU objcopy for uncompression.
--compress-debug-sections=zlib-gnu is unlikely ever used by anyone, so I do not
add a custom diagnostic.
Differential Revision: https://reviews.llvm.org/D128688
Currently, only custom sections can be selected by operations that use section
names, because only custom sections have explicit names (whereas known sections
have names defined by the spec and only use their indices in the binary format).
This CL makes objdopy use the spec-defined names for these sections, allowing
them to be used in operations such as dumping and removal.
This is a prerequisite for fixing
https://github.com/emscripten-core/emscripten/issues/13084
Differential Revision: https://reviews.llvm.org/D126509
When creating an archive, llvm-ar looks at the host to determine the
archive format to use, on Apple platforms this means it uses the
K_DARWIN format. K_DARWIN is _virtually_ equivalent to K_BSD, expect for
some very slight differences around padding, timestamps in deterministic
mode, and 64 bit formats. When updating an archive using llvm-ar, or
llvm-objcopy, Archive would try to determine the kind, but it was not
possible to get K_DARWIN in the initialization of the archive, because
they're virtually inciting usable from K_BSD, especially since the
slight differences only apply in very specific cases. This leads to
linker failures when the alignment workaround is not applied to an
archive copied with llvm-objcopy. This change teaches Archive to infer
the K_DARWIN type in the cases where it's possible and the first object
in the archive is a macho object. This avoids using the host triple to
determine this to not affect cross compiling.
Ideally we would eliminate the separate K_DARWIN type entirely since
it's not a truly separate archive type, but then we'd have to force the
macho workarounds on the BSD format generally. This might be acceptable
but then it would be unclear how to handle this case without forcing the
K_DARWIN64 format on all BSD users:
```
if (LastOffset >= Sym64Threshold) {
if (Kind == object::Archive::K_DARWIN)
Kind = object::Archive::K_DARWIN64;
else
Kind = object::Archive::K_GNU64;
}
```
The logic used to determine if the object is macho is derived from the
logic llvm-ar uses.
Previous context:
- 111cd669e90e5b2132187d36f8b141b11a671a8b
- 23a76be5adcaa768ba538f8a4514a7afccf61988
Differential Revision: https://reviews.llvm.org/D124895
All of the other tests here either check that the copy fails, or that
the resulting binary is the same, it seems like this check was omitted
for the universal object case.
Differential Revision: https://reviews.llvm.org/D125478
SUMMARY
1. Enable supporting the write operation of big archive.
2. the first commit come from https://reviews.llvm.org/D104367
3. refactor the first commit and implement writing symbol table.
4. fixed the bugs and add more test cases in the second commit.
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D123949
D122746 missed the following tests, so this patch adds them.
This patch refactors D122949, which marked the following tests XFAIL, but it makes more sense to temporarily add `--format=gnu` option because these tests aren’t testing `llvm-ar` and AIX won’t lose their coverage.
Reviewed By: jhenderson, MaskRay, DiggerLin
Differential Revision: https://reviews.llvm.org/D123063
Big archive writer operation is not currently supported so mark these tests XFAIL for now.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D122949
STB_GNU_UNIQUE is like STB_GLOBAL with extra semantics:
* gold and ld.lld: changed to STB_GLOBAL if --no-gnu-unique is specified
* glibc: unique even with dlopen `RTLD_LOCAL`, implies DF_1_NODELETE
Therefore, I think it makes sense for --weaken-symbol/--weaken-symbols/--weaken
to change STB_GNU_UNIQUE symbols.
binutils 2.39 will have the same behavior: https://sourceware.org/bugzilla/show_bug.cgi?id=28926
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D120638
When running llvm-bitcode-strip we want to remove the __LLVM
segment as well as the __bundle section when there are no other
sections in the segment.
Differential Revision: https://reviews.llvm.org/D120927
This diff adds functionality to the llvm-bitcode-strip tool for
stripping of LLVM bitcode sections.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D120669
Remove the executable name from the test match as this will have
a `.exe` suffix on windows.
Reviewed By: drodriguez
Differential Revision: https://reviews.llvm.org/D121000
Add the -o flag to specify an output path for llvm-bitcode-strip.
This matches the interface to the Xcode bitcode_strip tool.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D120731
Current objcopy implementation has a possibility to add or update sections.
The incoming section is specified as a pair: section name and name of the file
containing section data. The interface does not allow to specify incoming
section as a memory buffer. This patch adds possibility to specify incoming
section as a memory buffer.
Differential Revision: https://reviews.llvm.org/D120486
Summary: This is an initial implementation of lvm-objcopy for XCOFF32.
Currently only supports simple copying, op-passthrough to follow.
Reviewed By: jhenderson, shchenz
Differential Revision: https://reviews.llvm.org/D97656
The section name encoding for `llvm-objcopy` had two main issues, the
first is that the size used for the `snprintf` in the original code is
incorrect because `snprintf` adds a null byte, so this code was only
able to encode offsets of 6 digits - `/`, `\0` and 6 digits of the
offset - rather than the 7 digits it should support.
And the second part is that it didn't support the base64 encoding for
offsets larger than 7 digits.
This issue specifically showed up when using the `clang-offload-bundler`
with a binary containing a lot of symbols/sections, since it uses
`llvm-objcopy` to add the sections containing the offload code.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D118692
I discovered some of these tests had `cmp` statements that weren't
actually being run. I had also recently copied this broken setup for a
new test around chained fixups. Fixing this revealed that the binaries
did differ because of their code signature so I regenerated the fixture
here with this source:
```c
int main() {
return 0;
}
```
Passing `-Wl,-no_adhoc_codesign` on my M1 machine to make sure it didn't
get any signature.
Differential Revision: https://reviews.llvm.org/D119203
