Line ending policies were changed in the parent, dccebddb3b80. To make
it easier to resolve downstream merge conflicts after line-ending
policies are adjusted this is a separate whitespace-only commit. If you
have merge conflicts as a result, you can simply `git add --renormalize
-u && git merge --continue` or `git add --renormalize -u && git rebase
--continue` - depending on your workflow.
Historically, we've not automatically enforced how git tracks line
endings, but there are many, many commits that "undo" unintended CRLFs
getting into history.
`git log --pretty=oneline --grep=CRLF` shows nearly 100 commits
involving reverts of CRLF making its way into the index and then
history. As far as I can tell, there are none the other way round except
for specific cases like `.bat` files or tests for parsers that need to
accept such sequences.
Of note, one of the earliest of those listed in that output is:
```
commit 9795860250734e5c2a879546c534e35d9edd5944
Author: NAKAMURA Takumi <geek4civic@gmail.com>
Date: Thu Feb 3 11:41:27 2011 +0000
cmake/*: Add svn:eol-style=native and fix CRLF.
llvm-svn: 124793
```
...which introduced such a defacto policy for subversion.
With old versions of git, it's been a bit of a crap-shoot whether
enforcing storing line endings in the history will upset checkouts on
machines where such line endings are the norm. Indeed many users have
enforced that git checks out the working copy according to a global or
per-user config via core crlf, or core autocrlf.
For ~8 years now[1], however, git has supported the ability to "do as
the Romans do" on checkout, but internally store subsets of text files
with line-endings specified via a system of patterns in the
`.gitattributes` file. Since we now have this ability, and we've been
specifying attributes for various binary files, I think it makes sense
to rid us of all that work converting things "back", and just let git
handle the local checkout. Thus the new toplevel policy here is
* text=auto
In simple terms this means "unless otherwise specified, convert all
files considered "text" files to LF in the project history, but check
them out as expected on the local machine. What is "expected on the
local machine" is dependent on configuration and default.
For those files in the repository that *do* need CRLF endings, I've
adopted a policy of `eol=crlf` which means that git will store them in
history with LF, but regardless of user config, they'll be checked out
in tree with CRLF.
Finally, existing files have been "corrected" in history via `git add
--renormalize .`
End users should *not* need to adjust their local git config or
workflow.
[1]: git 2.10 was released with fixed support for fine-grained
line-ending tracking that respects user-config *and* repo policy. This
can be considered the point at which git will respect both the user's
local working tree preference *and* the history as specified by the
maintainers. See
https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248
for the release note.
Several lit tests look for messages with text generated from strerror()
such as "no such file or directory". The value can change slightly from
system to system. Use the llvm-lit macro `%errc_<ERRCODE>` instead.
This was really noticable on z/OS because the generated text includes an
error code as well as the text.
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.
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.
There are a few test that check access permissions, so they need to be
disabled when running the tests as root.
The most common use case for running tests as root is inside of a
container. GitHub Actions, for example, only supports running the root
user inside of containers, so this change is necessary in order to run
the tests inside of a container running in the GitHub Actions
environment.
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
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
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
Summary:
1. Added a new option object mode -X for llvm-ar. In AIX OS , there is a object mode option -X for ar command.
please see the "-X mode" part of https://www.ibm.com/docs/ko/aix/7.1?topic=ar-command
Specifies the type of object file ar 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
Processes both 32-bit and 64-bit object files
any
Processes all of the supported 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 ar to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
2. Before adding the new option -X, the default behaviors of llvm-ar like -Xany, but after the adding the new option -X, the default behaviors of llvm-ar change to -X32 ,in order to let some test cases which has 32bit and 64bit object file in the same llvm-ar command, we need to add the "export OBJECT_MODE=any" into test case to change the default behaviors of llvm-ar's object mode.
Reviewers: James Henderson, Owen Reynolds, Fangrui Song
Differential Revision: https://reviews.llvm.org/D127864
Recommit after revert.
This change adds testing for handling of bitcode files in archives,
particularly the creation of symbol tables and through MRI scripts.
Although there is some testing of bitcode handling in the archive
library testing, this was not covered.
Differential Revision: https://reviews.llvm.org/D129088
This change adds testing for handling of bitcode files in archives,
particularly the creation of symbol tables and through MRI scripts.
Although there is some testing of bitcode handling in the archive
library testing, this was not covered.
Differential Revision: https://reviews.llvm.org/D129088
This commit adds:
- Additional test coverage of the DELETE and END commands.
- File names to be read in the line endings test.
- A use of ADDLIB in the nonascii test.
Differential Revision: https://reviews.llvm.org/D128838
From binutils 2.34 onwards, ar supports --output to specify a directory
where archive members should be extracted to. Port this feature.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D128626
We did not properly handle using CREATETHIN in an MRI script and
attempting to use ADDLIB to add the contents of a regular archive. This
fix outputs a meaningful error message in this case and provides some
more testing.
Differential Revision: https://reviews.llvm.org/D128067
I discovered that when compared to GNU the llvm-ar MRI script parsing of
CREATE could lead to some strange behaviour. This fix improves the error
message in the case when no archive name is given and will not allow the
adding of members until CREATE is called. Along with this change I added
more testing of the CREATE command.
Differential Revision: https://reviews.llvm.org/D128055
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
Remove errant whitespace.
AIX uses big archive format so check for both !<arch> and <bigaf>.
Only the "gnu" format has thin archives; specify --format=gnu for
thin archive test-cases.
Summary:
llvm-ar can not read empty big archive correctly. it output error as
error: unable to load 'empty.a': truncated or malformed archive (characters in size field in archive member header are not all decimal numbers: '<bigaf>'
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D124017
The CREATE/CREATETHIN commands should overwrite the output file:
https://sourceware.org/binutils/docs/binutils/ar-scripts.html.
This fixes a regression for MRI scripts introduced in:
https://reviews.llvm.org/D123142 which put logic into
performWriteOperation. performWriteOperation is called for all MRI
commands that write an archive out (one's with a SAVE command).
performWriteOperation is unaware of MRI semantics and loads an
existing archive if present. If an existing archive is loaded, llvm-ar
checks the properties of the existing archive for decisions about the
output archive (for example making the output archive thin if the
existing one was). https://reviews.llvm.org/D123142 adds the following
logic...
if (OldArchive) {
if (Thin && !OldArchive->isThin())
fail("cannot convert a regular archive to a thin one");
if (OldArchive->isThin())
Thin = true;
}
... which errors for a script with CREATETHIN in effect if there is an
existing regular archive, and causes CREATE to output a thin archive
if there is an existing thin archive.
Differential Revision: https://reviews.llvm.org/D125439
SUMMARY
1. Enable supporting the write operation of big archive.
2. the first commit come from https://reviews.llvm.org/D104367
3. refactor the first commit and implement writing symbol table.
4. fixed the bugs and add more test cases in the second commit.
Reviewers: James Henderson
Differential Revision: https://reviews.llvm.org/D123949
Modify llvm-ar and llvm-ranlib to use the actual name of the executable
when printing the usage text via the '--help' flag.
Reviewers: Maskray, jhenderson, gbreynoo
Differential Revision: https://reviews.llvm.org/D124445
When using the L option to quick append a full archive to a thin
archive, the thin archive was being wrongly converted to a full archive.
I've fixed the issue and added a check for it in
thin-to-full-archive.test and expanded some tests.
Differential Revision: https://reviews.llvm.org/D123142
Two tests used the term "full archive" rather than "regular", these have
been updated including the test names. They now also use --thin rather
than the deprecated T. This change was made in preparation of D123142.
Differential Revision: https://reviews.llvm.org/D123778
Big archive writer operation is not currently supported so mark these tests XFAIL for now.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D122949
Summary:
when run "llvm-ar cr" on AIX OS , it created a gnu archive, it is not desirable in aix OS.
instead of creating a gnu archive, the patch will print a unsupport message for llvm-ar big archive write operation in AIX OS.
after implement the big archive operation, I will revert the XFAIL: AIX " and "--format=gnu" test cases in the patch.
Reviewer : James Henderson, Jinsong Ji
Differential Revision: https://reviews.llvm.org/D122746
llvm-ar silently converts a thin archive to a regular archive when you
specify a modification operation (e.g. 'r') without the 'T' modifier.
This change stops this from occuring. If a user is trying to convert
between thin and full archives then they can explicitly use the 'L'
command to createa new archive.
Differential Revision: https://reviews.llvm.org/D118693
In binutils, ar -s and randlib don't convert a thin archive to a regular one.
This behavior makes sense and this patch ports the behavior.
Reviewed By: gbreynoo
Differential Revision: https://reviews.llvm.org/D117443
In GNU ar (since 2008), the modifier 'T' means creating a thin archive.
In many other ar implementations (FreeBSD, macOS, elfutils, etc), -T
means "allow filename truncation of extracted files", as specified by
X/Open System Interface.
For portability, 'T' with thin archive semantics should be avoided.
See https://sourceware.org/bugzilla/show_bug.cgi?id=28759 binutils 2.38
will deprecate 'T' (without diagnostic) and add --thin.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D116979
binutils ar does not support one-dash long options (they conflict with
operation code and modifier flags).
```
% ar -help
ar: invalid option -- 'e'
...
% ar -version
ar: invalid option -- 'e'
...
% ar x --plugin=xx x.a # ok
% ar x -plugin=xx x.a
ar: two different operation options specified
% ar -plugin=/usr/lib/gcc/x86_64-linux-gnu/10/liblto_plugin.so x x.a
ar: x: No such file or directory
```
Drop one-dash long options to simplify code and match the usual practice for
command line utilities.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D116977
On z/OS, other error messages are not matched correctly in lit tests.
```
EDC5121I Invalid argument.
EDC5111I Permission denied.
```
This patch adds a lit substitution to fix it.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D95808
On z/OS, the following error message is not matched correctly in lit tests.
```
EDC5129I No such file or directory.
```
This patch uses a lit config substitution to check for platform specific error messages.
Reviewed By: muiez, jhenderson
Differential Revision: https://reviews.llvm.org/D95246
