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

[Object] Deduplicate the three createError functions

The Object library currently has three identical functions that translate a
Twine into a parser error. Until recently these functions have coexis

[Object] Deduplicate the three createError functions

The Object library currently has three identical functions that translate a
Twine into a parser error. Until recently these functions have coexisted
peacefully, but since D110320 Clang with enabled modules is now diagnosing that
we have several definitions of `createError` in Object.

This patch just merges them all and puts them into Object's `Error.h` where the
error code for `parse_failed` is also defined which seems cleaner and unbreaks
the bots.

Reviewed By: jhenderson

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

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...

Remove redundant "std::move"s in return statements

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

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] Ignore semicolons in module definition identifiers

Patch by David Major.

The NSS project's .def files make heavy use of semicolons in a
frightening attempt at portability:
https://hg.mozilla

[COFF] Ignore semicolons in module definition identifiers

Patch by David Major.

The NSS project's .def files make heavy use of semicolons in a
frightening attempt at portability:
https://hg.mozilla.org/projects/nss/raw-file/tip/lib/ckfw/capi/nsscapi.def

lld-link was treating the semicolon as part of the export name,
resulting in unresolved symbols. This patch includes ';' in the list of
characters to split on.

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

llvm-svn: 319933

show more ...

[COFF] Support ordinals in def files with space between @ and the number

Both GNU ld and MS link.exe support declaring ordinals this way.

A test will be added in lld.

Differential Revision: https:

[COFF] Support ordinals in def files with space between @ and the number

Both GNU ld and MS link.exe support declaring ordinals this way.

A test will be added in lld.

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

llvm-svn: 316690

show more ...

[COFF] Improve the check for functions that should get an extra underscore

This fixes exporting functions starting with an underscore, and
fully decorated fastcall/vectorcall functions.

Tests will

[COFF] Improve the check for functions that should get an extra underscore

This fixes exporting functions starting with an underscore, and
fully decorated fastcall/vectorcall functions.

Tests will be added in the lld repo.

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

llvm-svn: 316316

show more ...

[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386

Hook up the -k option (that in the original GNU dlltool removes the
@n suffix from the symbol that the final executable ends up

[llvm-dlltool] Fix creating stdcall/fastcall import libraries for i386

Hook up the -k option (that in the original GNU dlltool removes the
@n suffix from the symbol that the final executable ends up linked to).

In llvm-dlltool, make sure that functions end up with the undecorate
name type if this option is set and they are decorated. In mingw, when
creating import libraries from def files instead of creating an import
library as a side effect of linking a DLL, the symbol names in the def
contain the stdcall/fastcall decoration (but no leading underscore).

By setting the undecorate name type, a linker linking to the import
library will omit the decoration from the DLL import entry.

With this in place, mingw-w64 for i386 built with llvm-dlltool/clang
produces import libraries that actually work.

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

llvm-svn: 310990

show more ...

Object: preserve more information about DEF file

Preserve the actual library name as provided by the user. This is
required to properly replicate link's behaviour about the module import
name handl

Object: preserve more information about DEF file

Preserve the actual library name as provided by the user. This is
required to properly replicate link's behaviour about the module import
name handling. This requires an associated change to lld for updating
the tests for the proper behaviour for the import library module name
handling in various cases.

Associated tests will be part of the lld change.

llvm-svn: 308406

show more ...

Object: handle extensions properly in def files

When given an extension as part of the `library` directive in a def
file, the extension is preserved/honoured by link/lib. Behave similarly
when pars

Object: handle extensions properly in def files

When given an extension as part of the `library` directive in a def
file, the extension is preserved/honoured by link/lib. Behave similarly
when parsing the def file. This requires checking if a native extension
is provided as a keyword parameter. If no extension is present, append
a standard `.dll` or `.exe` extension.

This is best tested via lld, and I will add tests there as a follow up.

llvm-svn: 308383

show more ...

llvm: add llvm-dlltool support to the archiver

A PE COFF spec compliant import library generator.
Intended to be used with mingw-w64.

Supports:
PE COFF spec (section 8, Import Library Format)
PE CO

llvm: add llvm-dlltool support to the archiver

A PE COFF spec compliant import library generator.
Intended to be used with mingw-w64.

Supports:
PE COFF spec (section 8, Import Library Format)
PE COFF spec (Aux Format 3: Weak Externals)

Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D29892

This reapplies rL308329, which was reverted in rL308374

llvm-svn: 308379

show more ...

Revert r308329: llvm: add llvm-dlltool support to the archiver

This reverts commit r308329 because it broke buildbots.

llvm-svn: 308374

llvm: add llvm-dlltool support to the archiver

A PE COFF spec compliant import library generator.
Intended to be used with mingw-w64.

Supports:
PE COFF spec (section 8, Import Library Format)
PE CO

llvm: add llvm-dlltool support to the archiver

A PE COFF spec compliant import library generator.
Intended to be used with mingw-w64.

Supports:
PE COFF spec (section 8, Import Library Format)
PE COFF spec (Aux Format 3: Weak Externals)

Reviewed By: ruiu

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

llvm-svn: 308329

show more ...

Re-land "COFF: migrate def parser from LLD to LLVM"

This reverts commit r304561 and re-lands r303490 & co.

The fix was to use "SymbolName" when translating LLD's internal export
list to lib/Object'

Re-land "COFF: migrate def parser from LLD to LLVM"

This reverts commit r304561 and re-lands r303490 & co.

The fix was to use "SymbolName" when translating LLD's internal export
list to lib/Object's short export struct. The SymbolName reflects the
actual symbol name, which may include fastcall and stdcall mangling bits
not included in the /EXPORT or .def file EXPORTS name:

@@ -434,8 +434,7 @@ std::vector<COFFShortExport> createCOFFShortExportFromConfig() {
std::vector<COFFShortExport> Exports;
for (Export &E1 : Config->Exports) {
COFFShortExport E2;
- E2.Name = E1.Name;
+ // Use SymbolName, which will have any stdcall or fastcall qualifiers.
+ E2.Name = E1.SymbolName;
E2.ExtName = E1.ExtName;
E2.Ordinal = E1.Ordinal;
E2.Noname = E1.Noname;

llvm-svn: 304573

show more ...

COFF: Fix another StringRef return error

This should appease the lld build bot regression
Following up on rL303493

llvm-svn: 303494

COFF: migrate def parser from LLD to LLVM [1/2]

This is split up into two commits.
The will create the DEF parser in LLVM.
Check the following commit to see the removal from LLD

Reviewers: ruiu

Di

COFF: migrate def parser from LLD to LLVM [1/2]

This is split up into two commits.
The will create the DEF parser in LLVM.
Check the following commit to see the removal from LLD

Reviewers: ruiu

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

llvm-svn: 303490

show more ...