This reverts commit 9e3b64b9f95aadf57568576712902a272fe66503.
Reason: Broke the UBSan buildbot. See the comments in the pull request
(https://github.com/llvm/llvm-project/pull/85036) for more information.
--compress-sections is similar to --compress-debug-sections but applies
to arbitrary sections.
* `--compress-sections <section>=none`: decompress sections
* `--compress-sections <section>=[zlib|zstd]`: compress sections with zlib/zstd
Like `--remove-section`, the pattern is by default a glob, but a regex
when --regex is specified.
For `--remove-section` like options, `!` prevents matches and is not
dependent on ordering (see `ELF/wildcard-syntax.test`). Since
`--compress-sections a=zlib --compress-sections a=none` naturally allows
overriding, having an order-independent `!` would be confusing.
Therefore, `!` is disallowed.
Sections within a segment are effectively immutable. Report an error for
an attempt to (de)compress them. `SHF_ALLOC` sections in a relocatable
file can be compressed, but linkers usually reject them.
Link: https://discourse.llvm.org/t/rfc-compress-arbitrary-sections-with-ld-lld-compress-sections/71674
Pull Request: https://github.com/llvm/llvm-project/pull/85036
Add --skip-symbol and --skip-symbols options that allow to skip symbols
when executing other options that can change the symbol's name, binding
or visibility, similar to an existing option --keep-symbol that keeps a
symbol from being removed by other options.
Simplify --[de]compress-debug-sections to make it easier to add custom section [de]compression.
Change the following two behaviors to match GNU objcopy.
* --compress-debug-sections compresses SHF_ALLOC sections while GNU
doesn't.
* --decompress-debug-sections decompresses non-debug sections while GNU
doesn't.
Pull Request: https://github.com/llvm/llvm-project/pull/84885
Add options --set-symbol-visibility and --set-symbols-visibility to
manually change the visibility of symbols.
There is already an option to set the visibility of newly added symbols
via --add-symbol and --new-symbol-visibility. This option will allow to
change the visibility of already existing symbols.
(#79887) When the offset of a PT_INTERP segment equals the offset of a
PT_LOAD segment, we consider that the parent of the PT_LOAD segment is
the PT_INTERP segment. In `layoutSegments`, we place both segments to be
after the current `Offset`, ignoring the PT_LOAD alignment.
This scenario is possible with fixed section addresses, but doesn't
happen with default linker layouts (.interp precedes other sections and
is part of a PT_LOAD segment containing the ELF header and program
headers).
```
% cat a.s
.globl _start; _start: ret
.rodata; .byte 0
.tdata; .balign 4096; .byte 0
% clang -fuse-ld=lld a.s -o a -nostdlib -no-pie -z separate-loadable-segments -Wl,-Ttext=0x201000,--section-start=.interp=0x202000,--section-start=.rodata=0x202020,-z,nognustack
% llvm-objcopy a a2
% llvm-readelf -l a2 # incorrect offset(PT_LOAD)
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000040 0x0000000000200040 0x0000000000200040 0x0001c0 0x0001c0 R 0x8
INTERP 0x001001 0x0000000000202000 0x0000000000202000 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000200000 0x0000000000200000 0x000200 0x000200 R 0x1000
LOAD 0x001000 0x0000000000201000 0x0000000000201000 0x000001 0x000001 R E 0x1000
//// incorrect offset
LOAD 0x001001 0x0000000000202000 0x0000000000202000 0x000021 0x000021 R 0x1000
LOAD 0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x001000 RW 0x1000
TLS 0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x000001 R 0x1000
GNU_RELRO 0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x001000 R 0x1000
```
The same issue occurs for PT_TLS/PT_GNU_RELRO if we PT_TLS's alignment
is smaller and we place the PT_LOAD after PT_TLS/PT_GNU_RELRO segments
(not linker default, but possible with a `PHDRS` linker script command).
Fix#79887: when two segments have the same offset, order the one with a
larger alignment first. In the previous case, the PT_LOAD segment will
go before the PT_INTERP segment. In case of equal alignments, it doesn't
matter which segment is treated as the parent segment.
yaml2obj creates invalid object files even when the input was created by
obj2yaml using a valid object file. On the other hand, yaml2obj is used
to intentionally create invalid object files for testing purposes.
This update balances using specified input values when provided and
computing file offsets and sizes if necessary.
This fixes the issue mentioned here:
https://github.com/llvm/llvm-project/issues/57407
It prevents `llvm-objcopy` from removing the `.gnu _debuglink` section
when used with the `--strip-all` flag. Since `--strip-all` is the
default of `llvm-strip` the patch also prevents `llvm-strip` from
removing the `.gnu_debuglink` section.
In the change that added `--gap-fill`, the condition to choose the
sections to write in `BinaryWriter::write()` did not exclude zero-size
sections. However, zero-size sections did not have correct offsets
assigned in `BinaryWriter::finalize()`. The result is either a failed
assertion, or memory corruption due to writing to the buffer beyond its
size.
To fix this, exclude zero-size sections from writing. Also, add a zero-size
section to the test, which would trigger the problem.
The tests added in PR #65815 fail on Apple buildbot because the `od`
printed addresses have a different number of leading zeroes. Mask
leading zeroes with a regex.
To support the `od` output format on z/OS, add `--ignore-case` to FileCheck.
`--gap-fill <value>` fills the gaps between sections with a specified
8-bit value, instead of zero.
`--pad-to <address>` pads the output binary up to the specified load
address, using the 8-bit value from `--gap-fill` or zero.
These options are only supported for ELF input and binary output.
As of now, llvm-objcopy silently ignores a provided regex if it doesn't
compile.
This patch adds returning an error saying that a regex couldn't be
compiled, along with the compilation error message.
---------
Co-authored-by: James Henderson <46713263+jh7370@users.noreply.github.com>
Update this diagnostic to mention the reason (unmatched '['), matching
the other diagnostic about stray '\'. The original pattern is omitted,
as some users may mention the original pattern in another position, not
repeating it.
Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).
This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D155535
Currently, objcopy cannot set the new flag SHF_X86_64_LARGE. This change introduces the named flag "large" which translates to that section flag.
An "invalid argument" error is produced if a user attempts to set the flag on an architecture other than X86_64.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D153262
Apart from general feature parity, this is also necessary for enabling
ClangBuiltLinux that defaults to using LLVM tools.
While at it, add a missing comment for the Hexagon definition directly
above, so it doesn't get confused with the SPARC definitions.
Reviewed By: SixWeining, MaskRay, jhenderson
Differential Revision: https://reviews.llvm.org/D153609
llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.
This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.
Fix https://github.com/llvm/llvm-project/issues/62636
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D150276
This reverts commit eb1442d0f73c76cfb5051d133f858fe760d189cf.
The test tools/llvm-objcopy/ELF/binary-paddr.test fails on
ppc64be-clang-test-suite:
https://lab.llvm.org/buildbot#builders/231/builds/13120
Reverting at author's request.
llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.
This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.
Fix https://github.com/llvm/llvm-project/issues/62636
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D150276
This change to llvm-objcopy preserves the ELF section sh_link to .symtab
so long as none of the symbol table indices have been changed.
Previously, any invocation of llvm-objcopy including a "no-op" would
clear any section sh_link to .symtab.
Differential Revision: https://reviews.llvm.org/D150859
Add support for --dump-section on COFF files. This is helpful for
extracting specific content from an object file on Windows.
Differential Revision: https://reviews.llvm.org/D150305
Reviewed By: @alexander-shaposhnikov, @jhenderson, @hjyamauchi
The gABI prohibits multiple SH_SYMTAB sections. As a result,
llvm-objcopy was crashing in SymbolTableSection::removeSymbols(). This
patch fixes the issue by emitting an error if multiple SH_SYMTAB
sections are encountered when building an ELF object.
Fixes: https://github.com/llvm/llvm-project/issues/60448
Differential Revision: https://reviews.llvm.org/D143508
YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.
Differential Revision: https://reviews.llvm.org/D141848
Originally the test has a bug: in the input YAML `.symtab.dyn` section has a type
repeated twice with different values (SHT_SYMTAB and SHT_NOBITS). YAML parser
took SHT_NOBITS as a type of the section, so the test wasn't checking the desired
case.
This patch changes the test to verify that a section with SHT_SYMTAB type and
SHF_ALLOC flag is not removed when --strip-all-gnu flag present.
Differential Revision: https://reviews.llvm.org/D143086
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
