This patch changes the reproduce tests so that they no longer extract
the "long" paths of the generated reproduce tar archives. This
extraction prevented them from being run on Windows due to potential
issues relating to the Windows path length limit.
This patch also reduces the use of diff in these tests, as this was
raised as a performance concern in review D77659 and deemed unnecessary.
Differential Revision: https://reviews.llvm.org/D77750
r268231 made it so that the name of the --reproduce archive
is no longer listed in the response file. Previously, with
"--reproduce repro.tar" the response file would contain
repro/home/.../llvm-build-dir/.../foo.o
but after that change it contained
home/.../llvm-build-dir/.../foo.o
instead. The test added for this in r268231 checked that
the response file doesn't contain the string "repro", but
if the build dir is named e.g. "llvm-build-repro" then the
test fails because of that.
Change the assert to check that "repro" doesn't exist at the
beginning of the line instead. I verified that the test
still fails with r268231 reverted.
The test technically still fails if someone builds llvm in a directory
'/repro' below the root directory. Don't do that :)
llvm-svn: 370211
Summary:
I noticed that the reproducers files I was getting from building CheriBSD
didn't work because the --sysroot option was not being rewritten. I've
updated the test to also verify that the rewritten path matches uses a
FileCheck capature instead of a {{.+}} regex
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D40125
llvm-svn: 318656
The --symbol-ordering-file path was not being rewritten in the response file when
using --reproduce. This patch adds this to the list of switches that are rewritten,
so that the path is somewhere within the reproducer directory tree.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37480
llvm-svn: 312626
Summary:
If the linker is invoked with `--chroot /foo` and `/bar/baz.o`, it
tries to read the file from `/foo/bar/baz.o`. This feature is useful
when you are dealing with files created by the --reproduce option.
Reviewers: grimar
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D35517
llvm-svn: 308646
This is a fix for Bugzilla 28579.
The problem is that in --reproduce links the file path in -o option is
copied verbatim. When "lld @response.txt" link is run against the
extracted test case, if -o contains anything other that a plain file
name, the link will likely fail because the target directory in -o may
not exists. Stripping the directory path will create the output file
in the top level test directory.
Patch by Dmitry Mikulin!
llvm-svn: 293792
This is how we use TarWriter in LLD. Now LLD does not append
a file extension, so you need to pass `--reproduce foo.tar`
instead of `--reproduce foo`.
Differential Revision: https://reviews.llvm.org/D28103
llvm-svn: 291210
OpenBSD's cpio does not accept the -t option without -i.
Apparently some systems implement cpio -t as a shortcut
for cpio -it, the latter is the only thing that's documented.
This change avoids test failures on OpenBSD.
Patch by Mark Kettenis!
Differential Revision: https://reviews.llvm.org/D28002
llvm-svn: 290252
The feature is documented as
-----------------------------
The format of the dynamic list is the same as the version node
without scope and node name. See *note VERSION:: for more
information.
--------------------------------
And indeed qt uses a dynamic list with an 'extern "C++"' in it. With
this patch we support that
The change to gc-sections-shared makes us match bfd. Just because we
kept bar doesn't mean it has to be in the dynamic symbol table.
The changes to invalid-dynamic-list.test and reproduce.s are because
of the new parser.
The changes to version-script.s are the only case where we change
behavior with regards to bfd, but I would like to see a mix of
--version-script and --dynamic-list used in the wild before
complicating the code.
llvm-svn: 289082
We want --reproduce to
* not rewrite scripts and thin archives
* work with absolute paths
Given that, it pretty much has to create a full directory tree. On windows that
is problematic because of the very short maximum path limit. On most cases
users can still work around it with "--repro c:\r", but that is annoying and
not viable for automated testing.
We then need to produce some form of archive with the files. The first option
that comes to mind is .a files since we already have code for writing them.
There are a few problems with them
The format has a dedicated string table, so we cannot start writing it until
all members are known.
Regular implementations don't support creating directories. We could make
llvm-ar support that, but that is probably not a good idea.
The next natural option would be tar. The problem is that to support long path
names (which is how this started) it needs a "pax extended header" making this
an annoying format to write.
The next option I looked at seems a natural fit: cpio files.
They are available on pretty much every unix, support directories and long path
names and are really easy to write. The only slightly annoying part is a
terminator, but at least gnu cpio only prints a warning if it is missing, which
is handy for crashes. This patch still makes an effort to always create it.
llvm-svn: 268404
The test is now unexpectedly passing on
llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast which is treated as an error.
For now, disable Windows testing of the feature.
Rafael is working on generating an archive, which will hopefully allow
us to turn this test back on.
Unfortunately, we don't have a way to temporarily XFAIL this test just
on llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast.
llvm-svn: 268351
`REQUIRES: shell` is not appropriate because that would mean that there
are no windows bots testing this, and that is precisely where it needs
the most testing.
Rafael or Rui are working on generating an archive directly, which
should avoid this issue.
We can try to move the bot to a shorter build directory path.
llvm-svn: 268345
With this it is possible to use chroot/fakechroot to have a completely
reproducible link even when thin archives or linker scripts have
absolute paths.
llvm-svn: 268231
The aim of this patch is to make it easy to re-run the command without
updating paths in the command line. Here is a use case.
Assume that Alice is having an issue with lld and is reporting the issue
to developer Bob. Alice's current directly is /home/alice/work and her
command line is "ld.lld -o foo foo.o ../bar.o". She adds "--reproduce repro"
to the command line and re-run. Then the following text will be produced as
response.txt (notice that the paths are rewritten so that they are
relative to /home/alice/work/repro.)
-o home/alice/work/foo home/alice/work/foo.o home/alice/bar.o
The command also produces the following files by copying inputs.
/home/alice/repro/home/alice/work/foo.o
/home/alice/repro/home/alice/bar.o
Alice zips the directory and send it to Bob. Bob get an archive from Alice
and extract it to his home directory as /home/bob/repro. Now his directory
have the following files.
/home/bob/repro/response.txt
/home/bob/repro/home/alice/work/foo.o
/home/bob/repro/home/alice/bar.o
Bob then re-run the command with these files by the following commands.
cd /home/bob/repro
ld.lld @response.txt
This command will run the linker with the same command line options and
the same input files as Alice's, so it is very likely that Bob will see
the same issue as Alice saw.
Differential Revision: http://reviews.llvm.org/D19737
llvm-svn: 268169
When --reproduce <path> is given, then we need to concatenate input
file paths to the given path to save input files to the directory.
Previously, path concatenation didn't handle Windows drive letters
so it could generate invalid paths such as "C:\D:\foo". It also didn't
handle ".." path components, so it could produce some bad paths
such as "foo/../../etc/passwd".
In this patch, Windows drive letters and ".." are removed before
concatenating paths.
Differential Revision: http://reviews.llvm.org/D19551
llvm-svn: 267600
Previously, the test didn't work on Windows because it tried to
concatenate two (possibly) absolute paths. If two paths are absolute
paths that have drive letters, then the result would become something
like C:\foo\D:\bar. That's not a valid path. I changed the test to
use relative paths.
llvm-svn: 267588
--reproduce dumps the object files in a directory chosen
(preserving the file system layout) and the linker invocation
so that people can create an archive and upload for debugging.
Differential Revision: http://reviews.llvm.org/D19494
llvm-svn: 267497
Andrew Ng