[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all oc

[LLVM] Use {} instead of std::nullopt to initialize empty ArrayRef (#109133)

It is almost always simpler to use {} instead of std::nullopt to
initialize an empty ArrayRef. This patch changes all occurrences I could
find in LLVM itself. In future the ArrayRef(std::nullopt_t) constructor
could be deprecated or removed.

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] 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 ...

[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.

[IR][Object][NFC] Move ARM64EC name mangling helpers to Mangler.h. (#87191)

Move the implementation to llvm:Core to avoids including `COFF.h` in `Mangler.cpp`.

[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 ...

[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-readobj][Object][COFF] Include COFF import file machine type in format string. (#78366)

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

[NFC] add new function is64Bit for SymbolicFile class

Summary:

since the class 'SymbolicFile ' do not have a is64Bit() API , when we need to check whether a SymbolicFile object is 64bit or not. we

[NFC] add new function is64Bit for SymbolicFile class

Summary:

since the class 'SymbolicFile ' do not have a is64Bit() API , when we need to check whether a SymbolicFile object is 64bit or not. we need to write a function to do it, it maybe cause duplication code.

Reviewers: James Henderson, Fangrui Song
Differential Revision: https://reviews.llvm.org/D143097

show more ...

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUn

Cleanup LLVMObject headers

Most notably,

llvm/Object/Binary.h no longer includes llvm/Support/MemoryBuffer.h
llvm/Object/MachOUniversal*.h no longer include llvm/Object/Archive.h
llvm/Object/TapiUniversal.h no longer includes llvm/Object/TapiFile.h

llvm-project preprocessed size:
before: 1068185081
after: 1068324320

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119457

show more ...

[llvm] Fix header guards (NFC)

Identified with llvm-header-guard.

[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> getSymbolFlags().

This change enables getSymbolFlags() to return errors which benefit error reporting in clients.

Differential Revisi

[Object] Change uint32_t getSymbolFlags() to Expected<uint32_t> getSymbolFlags().

This change enables getSymbolFlags() to return errors which benefit error reporting in clients.

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

show more ...

[COFF] Fix /export:foo=bar when bar is a weak alias

Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.

[COFF] Fix /export:foo=bar when bar is a weak alias

Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.
However, when the symbol is re-exported under a new name, the linker has
to transfer the decorations from the exported symbol over to the new
name. This is implemented by taking the mangled symbol that was found in
the object and replacing the original symbol name with the export name.

Before this patch, LLD implemented the fuzzy search by adding an
undefined symbol with the unmangled name, and then during symbol
resolution, checking if similar mangled symbols had been added after the
last round of symbol resolution. If so, LLD makes the original symbol a
weak alias of the mangled symbol. Later, to get the original symbol
name, LLD would look through the weak alias and forward it on to the
import library writer, which copies the symbol decorations. This
approach doesn't work when bar is itself a weak alias, as is the case in
asan. It's especially bad when the aliasee of bar contains the string
"bar", consider "bar_default". In this case, we would end up exporting
the symbol "foo_default" when we should've exported just "foo".

To fix this, don't look through weak aliases to find the mangled name.
Save the mangled name earlier during fuzzy symbol lookup.

Fixes PR42074

Reviewers: mstorsjo, ruiu

Subscribers: thakis, llvm-commits

Tags: #llvm

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

llvm-svn: 362849

show more ...

[Object] Change SymbolicFile::printSymbolName to use Error

llvm-svn: 360414

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[COFF] Improve correctness of def parsing for GNU features

The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful

[COFF] Improve correctness of def parsing for GNU features

The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful for adding linker level aliases for function
in the import library) is a feature distinct and different from
the operator = used for exporting a function with a different
name (both in import library and DLL) than in the implementation
producing the DLL.

When creating an import library using dlltool, from a def file that
contains forwards (Func = OtherDll.Func), this shouldn't affect the
produced import library, which should still behave just as if it
was a normal exported function.

This clears a lot of confusion and subtle misunderstandings, and
avoids a parameter that was used to avoid creating weak aliases
when invoked from lld. (This parameter was added previously due to
the existing conflation of the two features.)

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

llvm-svn: 331859

show more ...

[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode

This (together with the corresponding LLD commit, that contains the
testcase updates) fixes PR35733.

Differential Rev

[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode

This (together with the corresponding LLD commit, that contains the
testcase updates) fixes PR35733.

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

llvm-svn: 323035

show more ...

Convert the archive writer to use Error.

This found one place in lld that was not checking the error.

llvm-svn: 313937

[COFF] Make the weak aliases optional

When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what a

[COFF] Make the weak aliases optional

When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.

This restores the behaviour of renamed exports to what it was in
4.0.

The other half of this commit, including test, goes into lld.

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

llvm-svn: 310991

show more ...