[llvm-strip] Preserve access/modification timestamps when -p is used.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 21491 Build 21491: arc lint + arc unit
Event Timeline
test/tools/llvm-objcopy/strip-preserve-time.test | ||
---|---|---|
1 | Have you run this test both on Windows and Linux to ensure the they work the same? I know a colleague had some issues with access times on Windows at one point, for example. | |
3 | The comments in the file should end in a full stop, I think. | |
5 | I'm slightly worried that this might lead to a flaky test, because there's a race condition here: if another process accesses the file some time between file creation and checking, then we'll presumably get a failure (and I could see a virus scanner doing just that...). | |
14 | I'd prefer it if you use a different output file for each case. It'll make it easier to debug any issues with failing tests, because all of the different cases will be available. | |
tools/llvm-objcopy/llvm-objcopy.cpp | ||
680 | Should this be static? |
test/tools/llvm-objcopy/strip-preserve-time.test | ||
---|---|---|
1 | I don't have access to a Windows machine, but I'll ask a coworker to patch it and take a look. I'd actually rather use stat if this is linux-only, but I assume that ls is more portable. | |
5 | I'm not sure if there's a good solution for this. At the very least, I can watch build bots once this is submitted to see if this test causes flakiness. Very little time goes by between file creation and running llvm-strip, so it _probably_ won't cause issues, but I don't know how virus scanners work. |
If I get a chance, I'll verify this on Windows. Otherwise, this LGTM.
test/tools/llvm-objcopy/strip-preserve-time.test | ||
---|---|---|
5 | Yeah, I don't really know either. If it starts causing flakiness, we might just want to sacrifice that part of the test, and just verify it manually... | |
35 | Nit: I don't think you need the 's' part of this command. |
test/tools/llvm-objcopy/strip-preserve-time.test | ||
---|---|---|
5 | So, apparently windows is fine with "ls -lu" etc., but barfs on the parens used to pipe several commands to FileCheck $ "C:\src\clang\bin\llvm-strip.EXE" "-p" "C:\src\clang\test\tools\llvm-objcopy\Output\strip-preserve-time.test.tmp.1.o" "-o" "C:\src\clang\test\tools\llvm-objcopy\Output\strip-preserve-time.test.tmp-preserved.1.o" $ ":" "RUN: at line 8" $ "(ls" "-lu" "C:\src\clang\test\tools\llvm-objcopy\Output\strip-preserve-time.test.tmp-preserved.1.o" # command stderr: '(ls': command not found error: command failed with exit status: 127 Splitting it into two with different access/modify time check-prefixes seems to work. |
llvm/trunk/test/tools/llvm-objcopy/strip-preserve-time.test | ||
---|---|---|
16–17 ↗ | (On Diff #161082) | Great! I think what you've done here is fine, but for reference, you could have done it in an equally valid way using output redirection. I think either approach works though. # RUN: ls -lu %t-preserved.2.o > %t.out.txt # RUN: ls -l %t-preserved.2.o >> %t.out.txt # RUN: FileCheck %s --input-file %t.out.txt --check-prefix=CHECK-PRESERVE |
Have you run this test both on Windows and Linux to ensure the they work the same? I know a colleague had some issues with access times on Windows at one point, for example.