maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/reproduce-error.s

15 lines
385 B
ArmAsm
Raw Normal View History

Disable cpio test on Windows again. The last fix is unlikely to solve the issue. Reverting it to the original file. llvm-svn: 286393
2016-11-10 04:54:01 +08:00
# REQUIRES: shell
[ELF] Move `# REQUIRES:` line to the top llvm-svn: 335625
2018-06-27 00:58:19 +08:00
# Extracting the tar archive can get over the path limit on windows.
Produce cpio files for --reproduce. 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
2016-05-04 01:30:44 +08:00
# RUN: rm -rf %t.dir
# RUN: mkdir -p %t.dir
# RUN: cd %t.dir
Use TarWriter to create tar archives instead of cpio. 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
2017-01-06 10:33:53 +08:00
# RUN: not ld.lld --reproduce repro.tar abc -o t 2>&1 | FileCheck %s
Produce cpio files for --reproduce. 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
2016-05-04 01:30:44 +08:00
# CHECK: cannot open abc: {{N|n}}o such file or directory
Use TarWriter to create tar archives instead of cpio. 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
2017-01-06 10:33:53 +08:00
# RUN: tar xf repro.tar
Disable cpio test on Windows again. The last fix is unlikely to solve the issue. Reverting it to the original file. llvm-svn: 286393
2016-11-10 04:54:01 +08:00
# RUN: FileCheck --check-prefix=RSP %s < repro/response.txt
Produce cpio files for --reproduce. 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
2016-05-04 01:30:44 +08:00
# RSP: abc
# RSP: -o t