History log of /llvm-project/llvm/lib/Object/ArchiveWriter.cpp (Results 1 – 25 of 138)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1
# 60a6e6fa 28-Sep-2024 Kazu Hirata <kazu@google.com>

[Object] Avoid repeated map lookups (NFC) (#110201)


Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# c675a9be 18-Jul-2024 pcc <peter@pcc.me.uk>

Object: Don't error out on malformed bitcode files.

An error reading a bitcode file most likely indicates that the file
was created by a compiler from the future. Normally we don't try to
implement

Object: Don't error out on malformed bitcode files.

An error reading a bitcode file most likely indicates that the file
was created by a compiler from the future. Normally we don't try to
implement forwards compatibility for bitcode files, but when creating
an archive we can implement best-effort forwards compatibility by
treating the file as a blob and not creating symbol index entries for
it. lld and mold ignore the archive symbol index, so provided that
you use one of these linkers, LTO will work as long as lld or the
gold plugin is newer than the compiler. We only ignore errors if the
archive format is one that is supported by a linker that is known to
ignore the index, otherwise there's no chance of this working so we
may as well error out. We print a warning on read failure so that
users of linkers that rely on the symbol index can diagnose the issue.

This is the same behavior as GNU ar when the linker plugin returns
an error when reading the input file. If the bitcode file is actually
malformed, it will be diagnosed at link time.

Reviewers: MaskRay, dwblaikie, jh7370

Reviewed By: MaskRay, dwblaikie, jh7370

Pull Request: https://github.com/llvm/llvm-project/pull/96848

show more ...


# 5523a473 10-Jul-2024 Jeff Niu <jeff@modular.com>

[llvm][object] Expose `writeArchiveToStream` (#98254)

This internal helper is a useful API to have, when one wants to write an
archive directly to some other preallocated stream.


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3
# 254bfe95 20-Mar-2024 Jacek Caban <jacek@codeweavers.com>

[llvm-ar][Object][COFF] Add support for EC symbols to llvm-ar. (#85230)

Make writeArchive IsEC argument optional and use EC symbol map when indicated by input object files.


Revision tags: llvmorg-18.1.2
# c7fc95ba 15-Mar-2024 Jacek Caban <jacek@codeweavers.com>

[Object][Archive][NFC] Create all symbolic files objects before calculating offsets. (#85229)

This is refactoring preparing to move UseECMap computation to the
archive writer. We currently require

[Object][Archive][NFC] Create all symbolic files objects before calculating offsets. (#85229)

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.

show more ...


# 20375777 13-Mar-2024 Jacek Caban <jacek@codeweavers.com>

[llvm-ar] Use COFF archive format for COFF targets. (#82898)

Detect COFF files by default and allow specifying it with --format
argument.

This is important for ARM64EC, which uses a separated sy

[llvm-ar] Use COFF archive format for COFF targets. (#82898)

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.

show more ...


# 1a6ec906 12-Mar-2024 Daniel Paoliello <danpao@microsoft.com>

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


# ba13fa2a 09-Mar-2024 Michael Spencer <bigcheesegs@gmail.com>

[llvm][Support] Add and use errnoAsErrorCode (#84423)

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare

[llvm][Support] Add and use errnoAsErrorCode (#84423)

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.

show more ...


Revision tags: llvmorg-18.1.1
# 13fd4bf4 27-Feb-2024 Jacek Caban <jacek@codeweavers.com>

[llvm-ar][Archive] Use getDefaultTargetTriple instead of host triple for the fallback archive format. (#82888)


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4
# 8a5aa103 24-Feb-2024 Jacek Caban <jacek@codeweavers.com>

Revert "[llvm-ar] Use COFF archive format for COFF targets." (#82889)

Reverts llvm/llvm-project#82642 for
lld/test/ELF/invalid/Output/data-encoding.test.tmp.a failures on
Windows.


# cf9201cf 24-Feb-2024 Jacek Caban <jacek@codeweavers.com>

[llvm-ar] Use COFF archive format for COFF targets. (#82642)

Detect COFF files by default and allow specifying it with --format
argument.

This is important for ARM64EC, which uses a separated sy

[llvm-ar] Use COFF archive format for COFF targets. (#82642)

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.

show more ...


Revision tags: llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# a5dc3f68 12-Jan-2024 Kazu Hirata <kazu@google.com>

[llvm] Use SmallString::operator std::string() (NFC)


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3
# 4a0ccfa8 13-Oct-2023 Kazu Hirata <kazu@google.com>

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.

show more ...


# bf0534e8 12-Oct-2023 Jacek Caban <jacek@codeweavers.com>

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


Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0
# f903119c 06-Sep-2023 zhijian <zhijian@ca.ibm.com>

Fixed a compile error on use of deleted function ¡®{anonymous}::MemberData::MemberData(const {anonymous}::MemberData&)

Summary:

There is compile error on https://lab.llvm.org/buildbot/#/builders/

Fixed a compile error on use of deleted function ¡®{anonymous}::MemberData::MemberData(const {anonymous}::MemberData&)

Summary:

There is compile error on https://lab.llvm.org/buildbot/#/builders/264/builds/1147/steps/5/logs/stdio
when commit in https://reviews.llvm.org/D144872

show more ...


# 4cc7c749 06-Sep-2023 zhijian <zhijian@ca.ibm.com>

[AIX] Align the content of an xcoff object file which has auxiliary header in big archive.

Summary:

if the member file is XCOFF object file and has auxiliary header, the content of the member file

[AIX] Align the content of an xcoff object file which has auxiliary header in big archive.

Summary:

if the member file is XCOFF object file and has auxiliary header, the content of the member file need to be aligned at the
MAX(maximum alignment of .text , maximum alignment of .data). The "maximum alignment of .text" and "maximum alignment of .data" are two
field of auxiliary header of XCOFF object file.

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

show more ...


Revision tags: llvmorg-17.0.0-rc4
# 111fcb0d 02-Sep-2023 Fangrui Song <i@maskray.me>

[llvm] Fix duplicate word typos. NFC

Those fixes were taken from https://reviews.llvm.org/D137338


# f740bcb3 22-Aug-2023 zhijian <zhijian@ca.ibm.com>

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


Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5
# 38d3c6cb 18-May-2023 zhijian <zhijian@ca.ibm.com>

[AIX] support 64bit global symbol table for big archive

Summary:

In big archive , there is 32bit global symbol table and 64 bit global symbol table. llvm-ar only support 32bit global symbol table t

[AIX] support 64bit global symbol table for big archive

Summary:

In big archive , there is 32bit global symbol table and 64 bit global symbol table. llvm-ar only support 32bit global symbol table this moment, we need to support the 64 bit global symbol table.

https://www.ibm.com/docs/en/aix/7.2?topic=formats-ar-file-format-big

Global Symbol Tables

Immediately following the member table, the archive file contains two global symbol tables. The first global symbol table locates 32-bit file members that define global symbols; the second global symbol table does the same for 64-bit file members. If the archive has no 32-bit or 64-bit file members, the respective global symbol table is omitted. The strip command can be used to delete one or both global symbol tables from the archive. The fl_gstoff field in the fixed-length header contains the offset to the 32-bit global symbol table, and the fl_gst64off contains the offset to the 64-bit global symbol table.

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

show more ...


Revision tags: llvmorg-16.0.4
# d78a7237 16-May-2023 zhijian <zhijian@ca.ibm.com>

[AIX] Fixed malformed big archive when total archive file size is large than 4Gbytes

Summary:

1. we use the unsigned type for NextOffset,PrevOffset ,GlobalSymbolOffset , MemberTableSize, it will ca

[AIX] Fixed malformed big archive when total archive file size is large than 4Gbytes

Summary:

1. we use the unsigned type for NextOffset,PrevOffset ,GlobalSymbolOffset , MemberTableSize, it will caused a malform big archive when the archive file size is large than 4G.
2. also fix a NFC comment on https://reviews.llvm.org/D142479#inline-1443927

Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D150462

show more ...


Revision tags: llvmorg-16.0.3
# e13d1b52 29-Apr-2023 NAKAMURA Takumi <geek4civic@gmail.com>

llvm/lib: Use <cerrno> explicitly since D146395 has hidden `errno`

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


# fae9d4df 28-Apr-2023 Qiongsi Wu <qwu@ibm.com>

[AIX][llvm-ar] Use the Correct Kind for Bitcode File Inputs

On AIX, when the input files are LLVM bitcode files, `llvm-ar` should set the archive kind to `K_AIXBIG` as well, instead of leaving it to

[AIX][llvm-ar] Use the Correct Kind for Bitcode File Inputs

On AIX, when the input files are LLVM bitcode files, `llvm-ar` should set the archive kind to `K_AIXBIG` as well, instead of leaving it to the default `K_GNU`.

Reviewed By: daltenty

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

show more ...


# eb56ef3e 21-Apr-2023 Jacek Caban <jacek@codeweavers.com>

[llvm-lib] Add support for ARM64EC libraries.

ARM64EC allows having both pure ARM64 objects and ARM64EC in the
same archive. This allows using single static library for linking
pure ARM64, pure ARM6

[llvm-lib] Add support for ARM64EC libraries.

ARM64EC allows having both pure ARM64 objects and ARM64EC in the
same archive. This allows using single static library for linking
pure ARM64, pure ARM64EC or mixed modules (what MS calls ARM64X:
a single module that may be used in both modes). To achieve that,
such static libraries need two separated symbol maps. The usual map
contains only pure ARM64 symbols, while a new /<ECSYMBOLS>/ section
contains EC symbols. EC symbols map has very similar format to the
usual map, except it doesn't contain object offsets and uses offsets
from regular map instead. This is true even for pure ARM64EC static
library: it will simply have 0 symbols in the symbol map.

Reviewed By: efriedma

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

show more ...


Revision tags: llvmorg-16.0.2, llvmorg-16.0.1
# 4fcbf384 23-Mar-2023 Jacek Caban <jacek@codeweavers.com>

[llvm-lib] Use COFF archive format in llvm-lib (other archive tools don't use this format).

We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section

[llvm-lib] Use COFF archive format in llvm-lib (other archive tools don't use this format).

We currently just use GNU format for llvm-lib. This mostly works, but
ARM64EC needs an additional section that does not really fit GNU format.
This patch implements writing in COFF format (as in, it's what archive
reader considers as K_COFF). This mostly requires symbol emitting symbol
map. Note that, just like in case of MSVC, symbols are de-duplicated in
both usual symbol table and the new symbol map.

Reviewed By: efriedma

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

show more ...


# 257dc54b 23-Mar-2023 Jacek Caban <jacek@codeweavers.com>

[Object][NFC] Don't insert string table into object members vector.

Having string table in members vector does not fit later patches in
this series. Symbol map needs to refer to objects' offsets, bu

[Object][NFC] Don't insert string table into object members vector.

Having string table in members vector does not fit later patches in
this series. Symbol map needs to refer to objects' offsets, but string
table should not be referenced. Also for ARM64EC, the new <ECSYMBOLS>
table is inserted after string table.

Reviewed By: efriedma

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

show more ...


123456