[Object] Fix updating darwin archives

When creating an archive, llvm-ar looks at the host to determine the
archive format to use, on Apple platforms this means it uses the
K_DARWIN format. K_DARWIN

[Object] Fix updating darwin archives

When creating an archive, llvm-ar looks at the host to determine the
archive format to use, on Apple platforms this means it uses the
K_DARWIN format. K_DARWIN is _virtually_ equivalent to K_BSD, expect for
some very slight differences around padding, timestamps in deterministic
mode, and 64 bit formats. When updating an archive using llvm-ar, or
llvm-objcopy, Archive would try to determine the kind, but it was not
possible to get K_DARWIN in the initialization of the archive, because
they're virtually inciting usable from K_BSD, especially since the
slight differences only apply in very specific cases. This leads to
linker failures when the alignment workaround is not applied to an
archive copied with llvm-objcopy. This change teaches Archive to infer
the K_DARWIN type in the cases where it's possible and the first object
in the archive is a macho object. This avoids using the host triple to
determine this to not affect cross compiling.

Ideally we would eliminate the separate K_DARWIN type entirely since
it's not a truly separate archive type, but then we'd have to force the
macho workarounds on the BSD format generally. This might be acceptable
but then it would be unclear how to handle this case without forcing the
K_DARWIN64 format on all BSD users:

```
if (LastOffset >= Sym64Threshold) {
if (Kind == object::Archive::K_DARWIN)
Kind = object::Archive::K_DARWIN64;
else
Kind = object::Archive::K_GNU64;
}
```

The logic used to determine if the object is macho is derived from the
logic llvm-ar uses.

Previous context:

- 111cd669e90e5b2132187d36f8b141b11a671a8b
- 23a76be5adcaa768ba538f8a4514a7afccf61988

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

show more ...

[Object] Skip section offset checking for /<XFGHASHMAP>/

Starting from Windows SDK for Windows 11 (10.0.22000.x), all the system
libraries (.lib files) contain a section with the '/<XFGHASHMAP>/' na

[Object] Skip section offset checking for /<XFGHASHMAP>/

Starting from Windows SDK for Windows 11 (10.0.22000.x), all the system
libraries (.lib files) contain a section with the '/<XFGHASHMAP>/' name.
This looks like the libraries are built with control flow guard enabled:
https://docs.microsoft.com/en-us/cpp/build/reference/guard-enable-control-flow-guard?view=msvc-170

To let the LLVM tools (llvm-ar, llvm-lib) work with these libraries,
this patch just skips the section offset check for sections with the
'/<XFGHASHMAP>/' name.

Closes: llvm/llvm-project#53814

Signed-off-by: Pavel Samolysov <pavel.samolysov@intel.com>

Reviewed By: jhenderson, thieta

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

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

[Object] Remove a redundant return statement (NFC)

Identified with readability-redundant-control-flow.

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org/D100651.

the rest of commits of the patch

1 Addressed the comments on the https://reviews.llvm.org/D100651
2 according to https://www.ibm.com/docs/en/aix/7.2?topic=formats-ar-file-format-big
using the "fl_fstmoff" for the first object file number, using "char ar_nxtmem[20]" to get next object file ,
using the "char fl_lstmoff[20]" for the last of the object file will fix the following problems:
2.1 can not correct reading a archive files which has padding data between too object file
2.2 can not correct reading a archive files from which some object file has be deleted

3 introduce a new derived class BigArchive for big ar file.

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

show more ...

Revert "[AIX] Support of Big archive (read)"

This appears to be causing the following build failures on green
dragon during stage2 builds on macOS:

/System/Volumes/Data/jenkins/workspace/apple-cla

Revert "[AIX] Support of Big archive (read)"

This appears to be causing the following build failures on green
dragon during stage2 builds on macOS:

/System/Volumes/Data/jenkins/workspace/apple-clang-stage2-configure-RA_osceola/clang.roots/BuildRecords/clang-9999.99_install/Objects/obj-llvm/./bin/clang++ -fno-stack-protector -fno-common -Wno-profile-instr-unprofiled -Wno-unknown-warning-option -Werror=unguarded-availability-new -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -fmodules -fmodules-cache-path=/System/Volumes/Data/jenkins/workspace/apple-clang-stage2-configure-RA_osceola/clang.roots/BuildRecords/clang-9999.99_install/Objects/obj-llvm/tools/clang/stage2-bins/module.cache -fcxx-modules -Xclang -fmodules-local-submodule-visibility -gmodules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-class-memaccess -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -fdiagnostics-color -O2 -gline-tables-only -DNDEBUG -arch x86_64 -arch arm64 -arch arm64e -isysroot /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk -mmacosx-version-min=10.10 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip tools/llvm-cov/CMakeFiles/llvm-cov.dir/llvm-cov.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/gcov.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CodeCoverage.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CoverageExporterJson.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CoverageExporterLcov.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CoverageFilters.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CoverageReport.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/CoverageSummaryInfo.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/SourceCoverageView.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/SourceCoverageViewHTML.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/SourceCoverageViewText.cpp.o tools/llvm-cov/CMakeFiles/llvm-cov.dir/TestingSupport.cpp.o -o bin/llvm-cov -Wl,-rpath,@loader_path/../lib lib/libLLVMCore.a lib/libLLVMSupport.a lib/libLLVMObject.a lib/libLLVMCoverage.a lib/libLLVMProfileData.a lib/libLLVMDebugInfoDWARF.a lib/libLLVMObject.a lib/libLLVMBitReader.a lib/libLLVMCore.a lib/libLLVMRemarks.a lib/libLLVMBitstreamReader.a lib/libLLVMMCParser.a lib/libLLVMTextAPI.a lib/libLLVMMC.a lib/libLLVMBinaryFormat.a lib/libLLVMDebugInfoCodeView.a lib/libLLVMSupport.a -lm /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/lib/libz.tbd /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk/usr/lib/libcurses.tbd lib/libLLVMDemangle.a && cd /System/Volumes/Data/jenkins/workspace/apple-clang-stage2-configure-RA_osceola/clang.roots/BuildRecords/clang-9999.99_install/Objects/obj-llvm/tools/clang/stage2-bins/tools/llvm-cov && xcrun dsymutil -o=llvm-cov.dSYM /System/Volumes/Data/jenkins/workspace/apple-clang-stage2-configure-RA_osceola/clang.roots/BuildRecords/clang-9999.99_install/Objects/obj-llvm/tools/clang/stage2-bins/bin/llvm-cov
Undefined symbols for architecture x86_64:
"llvm::object::CommonArchiveMemberHeader<llvm::object::BigArMemHdrType>::getRawAccessMode() const", referenced from:
vtable for llvm::object::BigArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::BigArMemHdrType>::getRawUID() const", referenced from:
vtable for llvm::object::BigArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::BigArMemHdrType>::getRawGID() const", referenced from:
vtable for llvm::object::BigArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::UnixArMemHdrType>::getRawAccessMode() const", referenced from:
vtable for llvm::object::ArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::UnixArMemHdrType>::getRawLastModified() const", referenced from:
vtable for llvm::object::ArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::BigArMemHdrType>::getRawLastModified() const", referenced from:
vtable for llvm::object::BigArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::BigArMemHdrType>::getOffset() const", referenced from:
vtable for llvm::object::BigArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::UnixArMemHdrType>::getRawUID() const", referenced from:
vtable for llvm::object::ArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::UnixArMemHdrType>::getRawGID() const", referenced from:
vtable for llvm::object::ArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
"llvm::object::CommonArchiveMemberHeader<llvm::object::UnixArMemHdrType>::getOffset() const", referenced from:
vtable for llvm::object::ArchiveMemberHeader in libLLVMObject.a(Archive.cpp.o)
ld: symbol(s) not found for architecture x86_64

https://smooshbase.apple.com/ci/job/apple-clang-stage2-configure-RA_osceola/30276/console

show more ...

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org/D100651.

the rest of commits of the patch

1 Addressed the comments on the https://reviews.llvm.org/D100651
2 according to https://www.ibm.com/docs/en/aix/7.2?topic=formats-ar-file-format-big
using the "fl_fstmoff" for the first object file number, using "char ar_nxtmem[20]" to get next object file ,
using the "char fl_lstmoff[20]" for the last of the object file will fix the following problems:
2.1 can not correct reading a archive files which has padding data between too object file
2.2 can not correct reading a archive files from which some object file has be deleted

3 introduce a new derived class BigArchive for big ar file.

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

show more ...

Revert "[AIX] Support of Big archive (read)"

This reverts commit 3130134d6e4823b5ee7619288a4b7e1e60831a82.

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org

[AIX] Support of Big archive (read)

Summary:

The patch is based on the EGuesnet's implement of the "Support of Big archive (read)
the first commit of the patch is come from https://reviews.llvm.org/D100651.

the rest of commits of the patch

1 Addressed the comments on the https://reviews.llvm.org/D100651
2 according to https://www.ibm.com/docs/en/aix/7.2?topic=formats-ar-file-format-big
using the "fl_fstmoff" for the first object file number, using "char ar_nxtmem[20]" to get next object file ,
using the "char fl_lstmoff[20]" for the last of the object file will fix the following problems:
2.1 can not correct reading a archive files which has padding data between too object file
2.2 can not correct reading a archive files from which some object file has be deleted

3 introduce a new derived class BigArchive for big ar file.

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

show more ...

[llvm-ar] Fix for handling thin archive with SYM64 and a test case for it

WHen thin archives are created which have symbol table of type SYM64 then all the tools will not work since they cannot read

[llvm-ar] Fix for handling thin archive with SYM64 and a test case for it

WHen thin archives are created which have symbol table of type SYM64 then all the tools will not work since they cannot read the files properly.
One can reproduce the problem as follows:
1. Take a hello world program and create an archive out of it. The SYM64_THRESHOLD=0 will force the generation of SYM64 symbol table.
clang -c hello.cpp
SYM64_THRESHOLD=0 llvm-ar crsT mylib.a hello.o
2. Now try to use any of the tools on this mylib.a and it will fail.
llvm-nm -M mylib.a

THis fix will eliminate these failures. A regression test is created in llvm/test/Object/archive-symtab.test

Reviewed By: MaskRay, Ramesh

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

show more ...

[NFC][libObject] clang-format Archive{.h,.cpp}

In preparation for D100651

static const char *const foo => const char foo[]

By default, a non-template variable of non-volatile const-qualified type
having namespace-scope has internal linkage, so no need for `static`.

[Object] Fix handling of large archive members

The archive library truncated the size of archive members whose size was
greater than max uint32_t. This patch fixes the issue and adds some unit
tests

[Object] Fix handling of large archive members

The archive library truncated the size of archive members whose size was
greater than max uint32_t. This patch fixes the issue and adds some unit
tests to verify.

Reviewed by: ruiu, MaskRay, grimar, rupprecht

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

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

[Object] Uncapitalize an error message

Test case will be added by my next commit.

llvm-svn: 372369

[llvm-ar] Fix support for archives with members larger than 4GB

llvm-ar outputs a strange error message when handling archives with
members larger than 4GB due to not checking file size when passing

[llvm-ar] Fix support for archives with members larger than 4GB

llvm-ar outputs a strange error message when handling archives with
members larger than 4GB due to not checking file size when passing the
value as an unsigned 32 bit integer. This overflow issue caused
malformed archives to be created.:

https://bugs.llvm.org/show_bug.cgi?id=38058

This change allows for members above 4GB and will error in a case that
is over the formats size limit, a 10 digit decimal integer.

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

llvm-svn: 366813

show more ...

[libObject][NFC] Include filename in error message

llvm-svn: 353341

[ADT] Add a fallible_iterator wrapper.

A fallible iterator is one whose increment or decrement operations may fail.
This would usually be supported by replacing the ++ and -- operators with
methods

[ADT] Add a fallible_iterator wrapper.

A fallible iterator is one whose increment or decrement operations may fail.
This would usually be supported by replacing the ++ and -- operators with
methods that return error:

class MyFallibleIterator {
public:
// ...
Error inc();
Errro dec();
// ...
};

The downside of this style is that it no longer conforms to the C++ iterator
concept, and can not make use of standard algorithms and features such as
range-based for loops.

The fallible_iterator wrapper takes an iterator written in the style above
and adapts it to (mostly) conform with the C++ iterator concept. It does this
by providing standard ++ and -- operator implementations, returning any errors
generated via a side channel (an Error reference passed into the wrapper at
construction time), and immediately jumping the iterator to a known 'end'
value upon error. It also marks the Error as checked any time an iterator is
compared with a known end value and found to be inequal, allowing early exit
from loops without redundant error checking*.

Usage looks like:

MyFallibleIterator I = ..., E = ...;

Error Err = Error::success();
for (auto &Elem : make_fallible_range(I, E, Err)) {
// Loop body is only entered when safe.

// Early exits from loop body permitted without checking Err.
if (SomeCondition)
return;

}
if (Err)
// Handle error.

* Since failure causes a fallible iterator to jump to end, testing that a
fallible iterator is not an end value implicitly verifies that the error is a
success value, and so is equivalent to an error check.

Reviewers: dblaikie, rupprecht

Subscribers: mgorny, dexonsmith, kristina, llvm-commits

Tags: #llvm

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

llvm-svn: 353237

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

Object: Find terminator correctly when reading long filenames in GNU archives (PR37244)

The code was previously relying on there being a null terminator
somewhere in (or after) the string table, som

Object: Find terminator correctly when reading long filenames in GNU archives (PR37244)

The code was previously relying on there being a null terminator
somewhere in (or after) the string table, something made less likely by
r330786.

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

llvm-svn: 331746

show more ...

Make 32-bit member offset in Archive::Symbol::getMember 64-bit

When accessing a member for a symbol with an offset greater than 2^32 -
1 the current Archive::Symbol::getMember implementation will ov

Make 32-bit member offset in Archive::Symbol::getMember 64-bit

When accessing a member for a symbol with an offset greater than 2^32 -
1 the current Archive::Symbol::getMember implementation will overflow
and cause unexpected behavior. This change simply fixes that. In
particular if you call "llvm-nm --print-armap" on an archive that has
this behavior you'll get an error.

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

llvm-svn: 316801

show more ...

Rename K_MIPS64 to K_GNU64

This patch renames K_MIPS64 to K_GNU64 as part of a change to add
support for writing archives with 64-bit indexes in the symbol table.

llvm-svn: 313787

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...