9eb80ab3787e1851be8c686651688e870b93506b changed the method for stack
pointer restoration to fix segmentation faults. However, I made a
mistake in the patch and swapped a != for a ==, which caused an
arbitrary register (the first one specified) to get restored rather than
the stack pointer specifically. This patch fixes that issue and adds
test coverage to prevent regression.
LLVM ObjectFile currently records the start offsets of sections as the
start of the section header, whereas most other tools (WABT, emscripten,
wasm-tools) record it as the start of the section content, after the
header. This affects binutils tools such as objdump and nm, but not
compilation/assembly (since that is driven by symbols and assembler
labels which already have their values inside the section payload rather
in the header. This patch updates LLVM to match the other tools.
This presents misleading and confusing output. If you have a function
defined at the beginning of an XCOFF object file, and you have a
function call to an external function, the function call disassembles as
a branch to the local function. That is,
`void f() { f(); g();}`
disassembles as
>00000000 <.f>:
0: 7c 08 02 a6 mflr 0
4: 94 21 ff c0 stwu 1, -64(1)
8: 90 01 00 48 stw 0, 72(1)
c: 4b ff ff f5 bl 0x0 <.f>
10: 4b ff ff f1 bl 0x0 <.f>
With this PR, the second call will display:
`10: 4b ff ff f1 bl 0x0 <.g> `
Using -r can help, but you still get the confusing output:
>10: 4b ff ff f1 bl 0x0 <.f>
00000010: R_RBR .g
Stubify broadly takes either tbd files or binary dylibs and turns them
into tbd files. In future patches, stubify will also allow additional
information to be embedded into the final TBD output too.
Add Util APIs to TextAPI for common operations used by readtapi for now.
The current (experimental) spec for WebAssembly shared libraries does
not include a full symbol table like the object format. This change
extracts symbol information from the normal wasm exports.
This is the first step in having the linker report undefined symbols
when linking with shared libraries. The current behaviour is to ignore
all undefined symbols when linking with `-pie` or `-shared`.
See https://github.com/emscripten-core/emscripten/issues/18198
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.
When llvm-objdump switched from cl:: to OptTable
(https://reviews.llvm.org/D100433), we dropped support for LLVM cl::
options. Some LLVM_DEBUG in `llvm/lib/Target/$target/MCDisassembler/`
files might be useful. Add -mllvm to allow dumping the information.
```
# -debug is available in an LLVM_ENABLE_ASSERTIONS=on build
llvm-objdump -d -mllvm -debug a.o > /dev/null
```
Link:
https://discourse.llvm.org/t/how-to-enable-debug-logs-in-llvm-objdump/75758
This is follow up for https://github.com/llvm/llvm-project/pull/71902.
The
default option --continue-on-cu-index-overflow returned an error
--continue-on-cu-index-overflow: missing argument. Changed it so that it
is the
same behavior as other flags like -gsplit-dwarf. Where
--continue-on-cu-index-overflow will default to continue, and user can
set mode
with --continue-on-cu-index-overflow=\<value>.
When a section contains two functions x1 and x2, we incorrectly display
x1's relocations when dumping x2 for `--disassemble-symbols=x2 -r`.
Fix#75539 by ignoring these relocations.
Summary:
Currently, we don't emit any of the AMDGPU specific flags and options
when printing in GNU-mode (the default). This patch adds extra code to
handle outputting these values to match the output from GNU's `readelf`
when used on an AMDGPU image.
Binutils 2.36 had a somewhat controversial change in how the
--preprocessor option was handled in GNU windres; previously, the option
was interpreted as a part of the command string, potentially containing
multiple arguments (which even was hinted at in the documentation).
In Binutils 2.36, this was changed to interpret the --preprocessor
argument as one argument (possibly containing spaces) pointing at the
preprocessor executable.
The existing behaviour where implicit arguments like -E -xc -DRC_INVOKED
are dropped if --preprocessor is specified, was kept.
This was a breaking change for some users of GNU windres, see
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594, and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f.
As multiple years have passed since, the behaviour change seems to be
here to stay, and any users of the previous form of the option have been
forced to avoid this construct. Thus update llvm-windres to match the
new way Binutils of handling this option.
One construct for specifying the path to the preprocessor, which works
both before and after binutils 2.36 (and this change in llvm-windres) is
to specify options like this:
--preprocessor path/to/executable --preprocessor-arg -E
--preprocessor-arg -xc -DRC_INVOKED
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.
The llvm::sys::ExecuteAndWait function doesn't resolve the file to be
executed from $PATH - i.e. it is similar to execv(), not execvp().
Due to this, specifying a --preprocessor argument to llvm-windres only
worked if it specified an absolute path to the preprocessor executable.
This was observed as one of the issues in
https://github.com/msys2/MINGW-packages/pull/19157.
Before d2fa6b694c2052cef1ddd507f6569bc84e3bbe35, this usage of
--preprocessor seemed to work, because the first argument of Args[] was
ignored and llvm-windres just executed the autodetected clang executable
regardless.
Also improve the error messages printed if preprocessing failed. (If the
preprocessor executable was started but itself returned an error, we
don't get any error string.)
If passing the windres option --preprocessor, the default arguments "-E
-xc -DRC_INVOKED" aren't passed. If these are passed explicitly by the
user via --preprocessor-arg instead, we need to make sure that "-xc" is
passed before the input filename, as this compiler/preprocessor option
only has an effect on input files that follow it.
This fixes one of the issues with llvm-windres observed in
https://github.com/msys2/MINGW-packages/pull/19157.
This patch adds in validation at two different levels that address
annotations are page aligned. This is necessary as otherwise the mmap
calls will fail as MAP_FIXED/MAP_FIXED_NOREPLACE require page aligned
addresses. This happens silently in the subprocess. This patch adds
validation at snippet parsing time to give feedback to the user and also
adds asserts at code generation/address usage time to ensure that other
users of the Exegesis APIs conform to the same requirements.
GNU addr2line supports lookup by symbol name in addition to the existing
address lookup. llvm-symbolizer starting from
e144ae54dcb96838a6176fd9eef21028935ccd4f supports lookup by symbol name.
This change extends this lookup with possibility to specify optional
offset.
Now the address for which source information is searched for can be
specified with offset:
llvm-symbolize --obj=abc.so "SYMBOL func_22+0x12"
It decreases the gap in features of llvm-symbolizer and GNU addr2line.
This lookup now is supported for code only.
Migrated from: https://reviews.llvm.org/D139859
Pull request: https://github.com/llvm/llvm-project/pull/75067
`--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.
This PR implements part 1 of yaml2obj for the GOFF Object File Format.
It adds support for the header and end records.
---------
Co-authored-by: Yusra Syeda <yusra.syeda@ibm.com>
This originally used the spelling Ws2_32 when added in
a5ffabce98a4b2e9d69009fa3e60f2b154100860, but was changed to WS2_32
in 042a2e8932984e6c9f2017cbabb5bc66ad5419ce with the intent to
use the canonical spelling from WinSDK, in order to aid cross
compilation from case sensitive file systems with WinSDK.
However, the WinSDK itself is self-inconsistent with respect
to file name cases. Headers refer to each other with many different
casings, so the original, out of the box casing doesn't work
on case sensitive file systems. Import libraries like these
use a variety of casings (some use all lowercase, some use
CamelCase, some all uppercase, and the suffix is either .lib,
.Lib or .LIB).
In order to use the WinSDK on a case sensitive file system, these
case issues has to be worked around somehow. Either by lowercasing
all files (and the #includes within them, and potentially keeping
symlinks with their original casing), or by setting up a Clang
case insensitive VFS overlay. LLVM's llvm/cmake/platforms/WinMsvc.cmake
sets up such a VFS overlay. For the linker, it creates a directory
with lowercase symlinks.
Therefore, the canonical way of handling these casing issues on
case sensitive file systems is to consistently use lowercase. That
is also what MinGW toolchains use.
As an example, the same list of system_libs refers to advapi32,
even if the actual file on disk in WinSDK is AdvAPI32.Lib.
Likewise, other in-tree build systems that picked up this change
for ws2_32 made it all lowercase, in
b07aaf8d3bde911638b0370037204898c3c2deb7 and
d22dad9f768fef376546053952f0b49b23bebfde. This also matches other
existing references to ws2_32 in e.g.
lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt and
lldb/source/Utility/CMakeLists.txt.
Extra libraries can show up here depending on how LLVM was configured,
so just allow extra libraries to show up instead of expecting an exact
list.
Partially reverts d7aee33029f2d029c16098bd0630831638c7038e.
The file name is WS2_32.Lib in all the Windows SDK versions I looked at.
You can get away with the incorrect casing on a case-insensitive file
system but it can matter for cross-compilation.
AF_UNIX sockets were added to Windows 10 build 17063 in 2017, older
versions of Windows will fail this test.
Also add a lit config so lit tests using sockets can do:
// REQUIRES: unix-sockets
(It would be cool if unit tests could use lit available_features)
Also fix llvm-config test that didn't fail when new libs are added.
The current warning emitted by dsymutil when it can't find a symbol in
an object file is worded rather poorly:
```
could not find object file symbol for symbol _foo
```
It's also lacking information that makes the warning actionable, such as
the object file it's looking at. This patch rewords the warning and adds
the object file path to the warning:
```
could not find symbol '_foo' in object file 'test.o'
```
rdar://119621065
Branch-absolute instructions are currently printed in decimal, and
negative addresses are printed as positive numbers.
With this change, addresses are printed in hex and negative addresses
are converted to an unsigned 32- or 64-bit address.
This patch switches to using explicit snippet crashes that contain more
information about the specific type of error (like the address for a
segmentation fault) that occurred. All these new error classes inherit
from SnippetExecutionFailure to allow for easily grabbing all of them in
addition to filtering for specific types using the standard LLVM error
primitives.
This patch introduces llvm-objdump tests for new `AARCH64_AUTH_RELR`,
`AARCH64_AUTH_RELRSZ` and `AARCH64_AUTH_RELRENT` dynamic tags.
Depends on https://github.com/llvm/llvm-project/pull/74874
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>
This reverts commit 30d700117b772d94d8474ec56bd6f9cc423fc613.
This relands commit 3ab41f912a6c219a93b87c257139822ea07c8863.
When I was updating the patch to use llvm::to_integer, I only ran the
lit tests and didn't run the unit tests, one of which started to fail.
This patch fixes the broken unit test.
