[AIX] supporting -X options for llvm-ranlib in AIX OS

Summary:

llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ https://github.ibm.com/compiler

[AIX] supporting -X options for llvm-ranlib in AIX OS

Summary:

llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ https://github.ibm.com/compiler/llvm-project/commit/4f2cfbe5314b064625b2c87bde6ce5c8d04004c5 | compiler/llvm-project@4f2cfbe ]] supports the -X options, but doesn't seem to accept them when running as llvm-ranlib.

In AIX OS , according to https://www.ibm.com/docs/en/aix/7.2?topic=r-ranlib-command

-X mode Specifies the type of object file ranlib should examine. The mode must be one of the following:

32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64, any
Processes both 32-bit and 64-bit object files

The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ranlib to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.

Reviewers: James Henderson, MaskRay, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142660

show more ...

[Object] Use COFF archive format for import libraries.

This is similar to D143540 for import libraries. ARM64EC will need it
for EC symbol table, but it should be fine for other targets as well
and

[Object] Use COFF archive format for import libraries.

This is similar to D143540 for import libraries. ARM64EC will need it
for EC symbol table, but it should be fine for other targets as well
and it improves MSVC compatibility. I left mingw case unchanged to be
safe, although I think that it wouldn't hurt to change that as well.

The visible effect in tests is a sorted symbol map.

Revieved By: mstorsjo
Differential Revision: https://reviews.llvm.org/D156473

show more ...

[Object] [NFC] Use llvm::COFF::is64Bit in COFF import file implementation.

Reviewed By: jhenderson, efriedma
Differential Revision: https://reviews.llvm.org/D156454

[llvm-lib] [llvm-readobj] [llvm-cvtres] Add Support for ARM64X object files.

Similar to D125411, but for ARM64X.

ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in on

[llvm-lib] [llvm-readobj] [llvm-cvtres] Add Support for ARM64X object files.

Similar to D125411, but for ARM64X.

ARM64X PE binaries are hybrids containing both ARM64EC and pure ARM64
variants in one file. They are usually linked by passing separate
ARM64EC and ARM64 object files to linker. Linked binaries use ARM64
machine and contain additional CHPE metadata in their load config.
CHPE metadata support is not part of this patch, I plan to send that later.

Using ARM64X as a machine type of object files themselves is somewhat
ambiguous, but such files are allowed by MSVC. It treats them as ARM64
or ARM64EC object, depending on the context. Such objects can be
produced with cvtres.exe -machine:arm64x.

Reviewed By: efriedma

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

show more ...

[NFC] Change strcpy to std::copy

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

[ARM64EC 1/?] Add parsing support to llvm-objdump/llvm-readobj.

This is the first patch of a patchset to add initial support for
ARM64EC. Basic documentation is available at
https://docs.microsoft.c

[ARM64EC 1/?] Add parsing support to llvm-objdump/llvm-readobj.

This is the first patch of a patchset to add initial support for
ARM64EC. Basic documentation is available at
https://docs.microsoft.com/en-us/windows/uwp/porting/arm64ec-abi .
(Discourse post:
https://discourse.llvm.org/t/initial-patches-for-arm64ec-windows-11-now-posted/62449
.)

The file format for ARM64EC is basically identical to normal ARM64.
There are a few extra sections, but the existing code for reading ARM64
object files just works.

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

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

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

[llvm-dlltool] Respect NONAME keyword

This adds proper handling of the NONAME-keyword, which makes llvm-dlltool
generate an import using the ordinal instead of the name.

Patch by by Jannik Vogel, t

[llvm-dlltool] Respect NONAME keyword

This adds proper handling of the NONAME-keyword, which makes llvm-dlltool
generate an import using the ordinal instead of the name.

Patch by by Jannik Vogel, test added by Stefan Schmidt.

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

llvm-svn: 361367

show more ...

[llvm-dlltool] Set a proper machine type for weak symbol object files

This makes GNU binutils not reject the libraries outright.

GNU ld handles weak externals slightly differently though, so it
can

[llvm-dlltool] Set a proper machine type for weak symbol object files

This makes GNU binutils not reject the libraries outright.

GNU ld handles weak externals slightly differently though, so it
can't use them for aliases in import libraries, but this makes GNU
ld able to use the rest of the import libraries.

LLD accepted object files with machine type 0 aka
IMAGE_FILE_MACHINE_UNKNOWN.

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

llvm-svn: 356982

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] Use symbolic constants instead of hardcoded numbers. NFCI.

Patch by Martell Malone.

llvm-svn: 337614

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

Fixed the gcc 'enumeral and non-enumeral type in conditional expression [-Werror=extra]' warning introduced by r320750

llvm-svn: 320868

Remove redundant includes from lib/Object.

llvm-svn: 320625

Convert the archive writer to use Error.

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

llvm-svn: 313937

Simplify writeArchive return type.

writeArchive returned a pair, but the first element of the pair is always
its first argument on failure, so it doesn't make sense to return it from
the function. T

Simplify writeArchive return type.

writeArchive returned a pair, but the first element of the pair is always
its first argument on failure, so it doesn't make sense to return it from
the function. This patch change the return type so that it does't return it.

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

llvm-svn: 312177

show more ...

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

[COFF] Add SymbolName as a distinct field in COFFImportFile

The previous Name and ExtName aren't enough to convey all the nuances
between weak aliases and stdcall decorated function names.

A test f

[COFF] Add SymbolName as a distinct field in COFFImportFile

The previous Name and ExtName aren't enough to convey all the nuances
between weak aliases and stdcall decorated function names.

A test for this will be added in LLD.

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

llvm-svn: 310988

show more ...

[llvm-dlltool] Write correct weak externals

Previously, the created object files for the import library were broken.
Write the symbol table before the string table. Simplify the code by
using a sepa

[llvm-dlltool] Write correct weak externals

Previously, the created object files for the import library were broken.
Write the symbol table before the string table. Simplify the code by
using a separate variable Prefix instead of duplicating a few lines.

Also update the coff-weak-exports to actually check that the generated
weak symbols can be found as intended.

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

llvm-svn: 309555

show more ...

[COFF] ARM64 support for COFFImportFile

A test will be committed separately in the lld repo.

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

llvm-svn: 308951

Object: rename parameter from DLLName to ImportName

When I originally wrote this code, I neglected the fact that the import
library may be created for executables. This name is not the name of
the

Object: rename parameter from DLLName to ImportName

When I originally wrote this code, I neglected the fact that the import
library may be created for executables. This name is not the name of
the DLL, but rather the name for the imported module. It will be
embedded into the IAT/ILT reference. Rename it to make it more obvious.
NFC.

llvm-svn: 308384

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