[llvm-dlltool] Handle MIPS R4000 architecture (#114621)

[llvm-lib][llvm-dlltool] Fix handling of invalid ARM64EC function names (#116250)

This is a follow-up to #115567. Emit an error for invalid function
names, similar to MSVC's `lib.exe` behavior.

[llvm-lib][llvm-dlltool] Fix handling of invalid ARM64EC function names (#116250)

This is a follow-up to #115567. Emit an error for invalid function
names, similar to MSVC's `lib.exe` behavior.

Returning an error from `writeImportLibrary` exposed bugs in error
handling by its callers, which have been addressed in this patch.

show more ...

[TableGen] Refactor Intrinsic handling in TableGen (#103980)

CodeGenIntrinsic changes:
- Use `const` Record pointers, and `StringRef` when possible.
- Default initialize several fields with th

[TableGen] Refactor Intrinsic handling in TableGen (#103980)

CodeGenIntrinsic changes:
- Use `const` Record pointers, and `StringRef` when possible.
- Default initialize several fields with their definition instead of in
the constructor.
- Simplify various string checks in the constructor using StringRef
starts_with()/ends_with() functions.
- Eliminate first argument to `setDefaultProperties` and use `TheDef`
class member instead.

IntrinsicEmitter changes:
- Emit `namespace llvm::Intrinsic` instead of nested namespaces.
- End generated comments with a .
- Use range based for loops, and early continue within loops.
- Emit `static constexpr` instead of `static const` for arrays.
- Change `compareFnAttributes` to use std::tie() to compare intrinsic
attributes and return a default value when all attributes are equal.

STLExtras:
- Add std::replace wrapper which takes a range.

show more ...

[llvm-dlltool] Use EXPORTAS name type for renamed imports on ARM64EC. (#99346)

Renamed entries are more tricky on ARM64EC than on other targets due
to additional symbols (we need `__imp_aux_*` in a

[llvm-dlltool] Use EXPORTAS name type for renamed imports on ARM64EC. (#99346)

Renamed entries are more tricky on ARM64EC than on other targets due
to additional symbols (we need `__imp_aux_*` in addition to `__imp_*`
and both mangled and unmangled symbol thunks). While we could extend
weak aliases to add them, it seems cleaner to just always use EXPORTAS
name type on ARM64EC targets. Unlike other targets, linkers supporting
ARM64EC need to support EXPORTAS, so there is no compatibility problem
with that.

show more ...

[llvm-dlltool] Fix renamed imports without a separate regular import entry (#98229)

Normally, when doing renamed imports, we do this by providing a
weak alias, towards another regular import, for t

[llvm-dlltool] Fix renamed imports without a separate regular import entry (#98229)

Normally, when doing renamed imports, we do this by providing a
weak alias, towards another regular import, for the symbol we
want to actually import. In a def file, this looks like this:

regularfunc
renamedfunc == regularfunc

However, if we want to link against a function in a DLL, where we
(intentionally) don't provide a regular import for that symbol
with the name in its DLL, doing the renamed import with a weak
alias doesn't work, as there's no symbol that the weak alias can
point towards.

We can't make up such an import either, as we may intentionally
not want to provide a regular import for that name.

This situation can either be resolved by using the "long" import
library format (as e.g. produced by GNU dlltool), or by using the
new short import library name type "export as".

This patch implements it by using the "export as" name type.

When producing a renamed import, defer emitting it until all regular
imports have been produced. If the renamed import refers to a
symbol that does exist as a regular import entry, produce a
weak alias, just as before. (This implementation also avoids needing
to know whether the symbol that the alias points towards actually
is prefixed or not, too.)

If the renamed import points at a symbol that isn't otherwise
available (or is available as a renamed symbol itself), generate
an "export as" import entry.

This name type is new, and is normally used in ARM64EC import
libraries, but can also be used for other architectures.

show more ...

[llvm-dlltool] Handle import renaming using other name types, when possible (#98228)

This avoids needing to use weak aliases for these cases. (Weak
aliases only work if there's another, regular imp

[llvm-dlltool] Handle import renaming using other name types, when possible (#98228)

This avoids needing to use weak aliases for these cases. (Weak
aliases only work if there's another, regular import entry that
provide the desired symbol from the DLL.)

show more ...

[llvm-dlltool] Remove the i386 underscore prefix from COFFImportFile::ImportName. NFC. (#98226)

On i386, regular C level symbols are given an underscore prefix
in the symbols on the object file lev

[llvm-dlltool] Remove the i386 underscore prefix from COFFImportFile::ImportName. NFC. (#98226)

On i386, regular C level symbols are given an underscore prefix
in the symbols on the object file level. However, the exported
names from DLLs usually don't have this leading underscore.

When specified in a def file like "symbol == dllname", the "dllname"
is the name of the exported symbol from the DLL, which will be
linked against from an object file symbol named "_symbol"
(on i386).

The mechanism where one symbol is redirected to another one in
an import library is implemented with weak aliases. In that case,
we need to have the object file symbol level name for the target
of the import, as we make one object file symbol point at another
one. Therefore, we added an underscore to the ImportName field.

(This mechanism, with weak aliases, only works as long as the
target also is exported as is, in that form - this issue is
dealt with in a later commit.)

For clarity, for potentially handling the import renaming in
other ways, store the ImportName field unprefixed, containing
the actual name to import from the DLL.

When creating the aliases, add the prefix as needed. This requires
passing an extra AddUnderscores parameter to the writeImportLibrary
function; this is a temporary measure, until alias creation is
reworked in a later commit.

This doesn't preserve the corner case of checking !isDecorated()
before adding the prefix. This corner case isn't tested by any
of our existing tests, and only would trigger for
fastcall/vectorcall/MS C++ functions - while these kinds of
renames primarily are used in mingw-w64-crt import libraries
(which primarily handle cdecl and stdcall functions).

show more ...

[llvm-dlltool] Respect the DATA flag when creating aliases (#98225)

[COFF] Rename the COFFShortExport::AliasTarget field. NFC. (#89039)

It turns out that the previous name is vaguely misleading.

When operating on a def file like "symbolname == dllname", that is

[COFF] Rename the COFFShortExport::AliasTarget field. NFC. (#89039)

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.

show more ...

[Object][COFF][NFC] Don't use inline function for COFFImportFile::printSymbolName. (#87195)

Fixes BUILD_SHARED_LIBS builds after #87191 made helpers non-inline.

[llvm-dlltool][llvm-lib][COFF] Don't override NONAME exports with demangled ARM64EC symbols. (#86722)

[llvm-lib] Use ARM64EC machine type for import libraries when -machine:arm64x is used. (#85972)

This is compatible with MSVC, `-machine:arm64x` is essentially an alias
to `-machine:arm64ec`. To mak

[llvm-lib] Use ARM64EC machine type for import libraries when -machine:arm64x is used. (#85972)

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.

show more ...

[Arm64EC] Copy import descriptors to the EC Map (#84834)

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

[Arm64EC] Copy import descriptors to the EC Map (#84834)

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.

show more ...

[llvm-dlltool] Add ARM64EC target support. (#81624)

Add new target and a new -n option allowing to specify native module
definition file, similar to how -defArm64Native works in llvm-lib. This
als

[llvm-dlltool] Add ARM64EC target support. (#81624)

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.

show more ...

[Object][COFF][NFC] Make writeImportLibrary NativeExports argument optional. (#81600)

It's not interesting for majority of downstream users.

[llvm-lib] Add support for -defArm64Native argument. (#81426)

This can be used to create import libraries that contain both ARM64EC
and native exports. The implementation follows observed MSVC lib.

[llvm-lib] Add support for -defArm64Native argument. (#81426)

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.

show more ...

[llvm-lib][Object] Add support for EC importlib symbols. (#81059)

ARM64EC import libraries expose two additional symbols: mangled thunk
symbol (like `#func`) and auxiliary import symbol (like`__imp

[llvm-lib][Object] Add support for EC importlib symbols. (#81059)

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.

show more ...

[llvm-lib][llvm-dlltool][Object] Add support for EXPORTAS name types. (#78772)

EXPORTAS is a new name type in import libraries. It's used by default on ARM64EC,
but it's allowed on other platforms

[llvm-lib][llvm-dlltool][Object] Add support for EXPORTAS name types. (#78772)

EXPORTAS is a new name type in import libraries. It's used by default on ARM64EC,
but it's allowed on other platforms as well.

show more ...

[llvm-readobj][Object][COFF] Print COFF import library symbol export name. (#78769)

getExportName implementation is based on lld-link. In its current form,
it's mostly about convenience, but it wil

[llvm-readobj][Object][COFF] Print COFF import library symbol export name. (#78769)

getExportName implementation is based on lld-link. In its current form,
it's mostly about convenience, but it will be more useful for EXPORTAS
support, for which export name is not possible to deduce from other
printed properties.

show more ...

[llvm-lib][Object][COFF] Use ARM64 machine type for import library descriptor objects. (#78537)

[llvm-readobj][Object][COFF] Include COFF import file machine type in format string. (#78366)

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::

[llvm] Use StringRef::{starts,ends}_with (NFC) (#74956)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[llvm-lib] [Object] Use ECSYMBOLS section for ARM64EC importlib symbols. (#68328)

[NFC] Use const references to avoid copying objects in for-loops

Differential Revision: https://reviews.llvm.org/D139487

Object: account for short output names (#66532)

The import library thunk name suffix uses the stem of the file. We
currently would attempt to trim the suffix by dropping the trailing 4
characters

Object: account for short output names (#66532)

The import library thunk name suffix uses the stem of the file. We
currently would attempt to trim the suffix by dropping the trailing 4
characters (under the assumption that the output name was `.lib`). This
now uses the `llvm::sys::path` API for computing the stem. This avoids
an assertion failure when the name is less the 4 characters and
assertions are enabled.

show more ...