On a few compilers (clang 11/12 for example [1]), the following does not
result in a copy elision, and since `Error`'s copy dtor is elided,
results in a compile error:
```
Expect<Something> foobar() {
...
if (Error E = aCallReturningError())
return E;
...
}
```
Moving `E` would, conversely, result in the pessimizing-move warning on
more recent clangs ("moving a local object in a return statement
prevents copy elision")
We just need to make the `Expected` ctor taking an `Error` take it as a
r-value reference.
[1] https://lab.llvm.org/buildbot/#/builders/54/builds/10505
`Count` and `Skip` should use `uint64_t` as they are encoded/decoded
using 64-bit ULEB128.
In `*_OPCODE_DO_*_ULEB_TIMES_SKIPPING_ULEB`, `Skip` could be encoded as
a two's complement for moving `SegmentOffset` backwards. Having a 32-bit
`Skip` truncates the encoded value and leads to a malformed
`AdvanceAmount`
and invalid `SegmentOffset` that extends past valid sections.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
70 under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
In ELF, relocatable files generated for x86-32 and some code models of
x86-64 (medium, large) may reference the special symbol
`_GLOBAL_OFFSET_TABLE_` that is not used in the IR. In an LTO link, if
there is no regular relocatable file referencing the special symbol, the
linker may not define the symbol and lead to a spurious "undefined
symbol" error.
Fix#61101: record that `_GLOBAL_OFFSET_TABLE_` is used in the IR symbol
table.
Note: The `PreservedSymbols` mechanism
(https://reviews.llvm.org/D112595) that just sets `FB_used` is not
applicable.
The `getRuntimeLibcallSymbols` for extracting lazy runtime library
symbols is for symbols that are "always" potentially used, but linkers
don't have the code model information to make a precise decision.
Pull Request: https://github.com/llvm/llvm-project/pull/89463
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
It turns out that the previous name is vaguely misleading.
When operating on a def file like "symbolname == dllname", that is
supposed to make an import library entry, that when the symbol
"symbolname" links against this, it imports the DLL symbol "dllname"
from the referenced DLL. This doesn't need to involve any alias, and it
doesn't need to imply that "dllname" is available on its own as a
separate symbol in the import library at all.
GNU dlltool implements import libraries in the form of "long import
library", where each member is a regular object file with section chunks
that compose the relevant .idata section pieces. There, this kind of
import renaming does not involve any form of aliases, but the right
.idata section just gets a different string than the symbol name.
It's a common pattern that we have a machine type, but we don't care
which ARM64* platform we're dealing with. We already have
isAnyArm64 for that, but it does not fit cases where we use a switch
statement. With this helper, it's easy to simplify such cases by using
Triple::ArchType instead of machine type.
The content of a GOFF record is always dumped if NDEBUG is not defined,
which produces rather confusing output. This changes wrap the dumping
code in LLVM_DEBUG, so the dump is only done when debug output of this
module is requested.
This change introduces a version 3 of the PSV data that includes support
for the name of the entry function as an offset into StringTable data to
a null-terminated utf-8 string.
Additional tests were added to ensure that the new value was properly
serialized/deserialized from object data.
Fixes#80175
---------
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
This change introduces a version 3 of the PSV data that includes support
for the name of the entry function as an offset into StringTable data to
a null-terminated utf-8 string.
Additional tests were added to ensure that the new value was properly
serialized/deserialized from object data.
Fixes#80175
---------
Co-authored-by: Cooper Partin <coopp@ntdev.microsoft.com>
This is compatible with MSVC, `-machine:arm64x` is essentially an alias
to `-machine:arm64ec`. To make a type library that exposes both native
and EC symbols, an additional `-defArm64Native` argument is needed in
both cases.
Defines a subset of attributes and emits them to a section called
.hexagon.attributes.
The current attributes recorded are the attributes needed by
llvm-objdump to automatically determine target features and eliminate
the need to manually pass features.
This is refactoring preparing to move UseECMap computation to the
archive writer. We currently require writeArchive caller to pass that.
This is not practical for llvm-ar, which currently interprets at most
one passed object. For a reliable UseECMap, we need to interpret all
symbolic objects: we may have, for example, a list of x86_64 files
followed by aarch64 file, which indicates that we should use EC map for
x86_64 objects.
This commit interprets symbolic files in a separated pass, which will be
a convenient place to implement UseECMap computation in the follow up.
It also makes accessing the next member for AIX big archive offset
computation a bit easier.
Detect COFF files by default and allow specifying it with --format
argument.
This is important for ARM64EC, which uses a separated symbol map for EC
symbols. Since K_COFF is mostly compatible with K_GNU, this shouldn't
really make a difference for other targets.
This originally landed as #82642, but was reverted due to test failures
in tests using no symbol table. Since COFF symbol can't express it,
fallback to GNU format in that case.
As noted in <https://github.com/llvm/llvm-project/pull/78537>, MSVC
places import descriptors in both the EC and regular map - that PR moved
the descriptors to ONLY the regular map, however this causes linking
errors when linking as Arm64EC:
```
bcryptprimitives.lib(bcryptprimitives.dll) : error LNK2001: unresolved external symbol __IMPORT_DESCRIPTOR_bcryptprimitives (EC Symbol)
```
This change copies import descriptors from the regular map to the EC
map, which fixes this linking error.
LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.
This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.
This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.
Detect COFF files by default and allow specifying it with --format
argument.
This is important for ARM64EC, which uses a separated symbol map for EC
symbols. Since K_COFF is mostly compatible with K_GNU, this shouldn't
really make a difference for other targets.
getSymbolSize was recently added to WasmObjectFile and has correct sizes
for most symbol types. This makes llvm-symbolizer correctly symbolize
addresses in the middle of the symbol.
When reworking the test I also noticed that the DWARF info seems to be
wrong for the first instruction in each function. I noted that in the test
comments but didn't attempt to fix here.
The section headers for XCOFF files have a subtype flag for Dwarf
sections. This PR updates obj2yaml, yaml2obj, and llvm-readobj so that
they recognize the subtype.
Currently the address reported by binutils for a global is its index;
but its offset (in the file or section) is more useful for binary size
attribution.
This PR treats globals similarly to functions, and tracks their offset
and size. It also centralizes the logic differentiating linked from object
and dylib files (where section addresses are 0).
Add new target and a new -n option allowing to specify native module
definition file, similar to how -defArm64Native works in llvm-lib. This
also changes archive format to use K_COFF like non-mingw targets. It's
required on ARM64EC, but it should be fine for other targets too.
The dot is too confusing for tools. Output temporaries would have
'10.3-generic' so tools could parse it as an extension, device libs &
the associated clang driver logic are also confused by the dot.
After discussions, we decided it's better to just remove the '.' from
the target name than fix each issue one by one.
This can be used to create import libraries that contain both ARM64EC
and native exports. The implementation follows observed MSVC lib.exe
behaviour. It's ignored on targets other than ARM64EC.
These generic targets include multiple GPUs and will, in the future,
provide a way to build once and run on multiple GPU, at the cost of less
optimization opportunities.
Note that this is just doing the compiler side of things, device libs an
runtimes/loader/etc. don't know about these targets yet, so none of them
actually work in practice right now. This is just the initial commit to
make LLVM aware of them.
This contains the documentation changes for both this change and #76954
as well.
ARM64EC import libraries expose two additional symbols: mangled thunk
symbol (like `#func`) and auxiliary import symbol (like`__imp_aux_func`).
The main functional change with this patch is that those symbols are
properly added to static library ECSYMBOLS.
nm already prints sizes for data symbols. Do that for function symbols
too, and update objdump to also print size information.
Implements item 3 from https://github.com/llvm/llvm-project/issues/76107
Summary:
Currently, the linker wrapper sorts input files into different link
jobs according to their architectures. Here we assume each architecture
is a unique and incompatible link job unless they are specifically
marked compatible. This patch simply adds an `all` target to represent
an architecture that should be linked against every single other
architecture.
This will be useful for modelling generic IR such as the ROCm device
libraries or the NVPTX libdevice.
Currently symbol info is generated from a linking section or from export
names. This PR generates symbols in a WasmObjectFile from the name
section as well, which allows tools like objdump and nm to show useful
information for more linked binaries. There are some limitations:
most notably that we don't assume any particular ABI, so we don't get
detailed information about data symbols if the segments are merged
(which is the default).
Covers most of the desired functionality from #76107
Wasm has no unified virtual memory space as other object formats and
architectures do, so previously WasmObjectFile reported 0 for all
section addresses, and until 428cf71ff used section offsets for function
symbols. Now we use file offsets for function symbols, and this change
switches section addresses to do the same (in linked files). The main
result of this is that objdump now reports VMAs in section listings, and
also uses file offets rather than section offsets when disassembling
linked binaries (matching the behavior of other disassemblers and stack
traces produced by browwsers). To make this work, this PR also updates
objdump's generation of synthetics fallback symbols to match lib/Object
and also correctly plumbs symbol types for regular and dummy symbols
through to the backend to avoid needing special knowledge of address 0.
This also paves the way for generating symbols from name sections rather
than symbol tables or imports (see #76107) by allowing the
disassembler's synthetic fallback symbols match the name-section
generated symbols (in a followup PR).
This code appears to be a hack to set the features to include compressed
instructions if the ELF EFLAGS flags bit is present, but the ELF
attribute for the ISA string is no present or not accurate.
We can't remove the hack because llvm-mc doesn't create ELF attributes
by default so a lot of tests fail to disassembler properly. Using clang
as the assembler does set the attributes.
This patch changes the hack to only set Zca since that is the minimum
implied by the flag. Setting anything else potentially conflicts with
the ISA string containing Zcmp or Zcmt.
JITLink also needs to be updated to recognize Zca in addition to C.
