Add a warning when the timestmap doesn't match between the object file and the debug map entry. We were already emitting such warnings for archive members and swift interface files. This patch also unifies the warning across all three.
Details
Diff Detail
Event Timeline
llvm/tools/dsymutil/BinaryHolder.cpp | ||
---|---|---|
103 | If I'm reading this right, we are warning for archive members (where the timestamp is used to disambiguate between same-named objects in different slices) only in verbose mode and here always? I would have expected it to be the other way round or at least consistent between the two. |
llvm/tools/dsymutil/BinaryHolder.cpp | ||
---|---|---|
103 | An archive can contain multiple files with the same name but different timestamps. If we don't find a perfect match, we'll error out (see the continue on line 202), so this is actually a stronger requirement than for object and swift interface files, where we'll print the warning but use the file regardless. |
llvm/tools/dsymutil/BinaryHolder.cpp | ||
---|---|---|
103 | Oh, this would print the warning even if we just haven't yet found the exact match because it comes later? That would be bad! |
Looks like this breaks tests on windows even after all the fix attempts: http://45.33.8.238/win/31260/step_11.txt
The test is just broken. Tests are not allowed to modify the source as they run. I'm sorry but I need to revert this. If you need help testing on a read-only source checkout, please let me know.
FAIL: LLVM :: tools/dsymutil/debug-map-parsing.test (66341 of 73748) ******************** TEST 'LLVM :: tools/dsymutil/debug-map-parsing.test' FAILED ******************** Script: -- : 'RUN: at line 1'; touch /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic.macho.x86_64.o : 'RUN: at line 2'; /tmp/_update_lc/r/bin/dsymutil -dump-debug-map -oso-prepend-path=/home/dave/ro_s/lp/llvm/test/tools/dsymutil /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic.macho.x86_64 | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/llvm/test/tools/dsymutil/debug-map-parsing.test : 'RUN: at line 3'; /tmp/_update_lc/r/bin/dsymutil -dump-debug-map -oso-prepend-path=/home/dave/ro_s/lp/llvm/test/tools/dsymutil /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic-lto.macho.x86_64 | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/llvm/test/tools/dsymutil/debug-map-parsing.test --check-prefix=CHECK-LTO : 'RUN: at line 4'; /tmp/_update_lc/r/bin/dsymutil -verbose -dump-debug-map -oso-prepend-path=/home/dave/ro_s/lp/llvm/test/tools/dsymutil /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic-archive.macho.x86_64 2>&1 | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/llvm/test/tools/dsymutil/debug-map-parsing.test --check-prefix=CHECK-ARCHIVE : 'RUN: at line 5'; /tmp/_update_lc/r/bin/dsymutil -dump-debug-map /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic.macho.x86_64 2>&1 | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/llvm/test/tools/dsymutil/debug-map-parsing.test --check-prefix=NOT-FOUND : 'RUN: at line 6'; not /tmp/_update_lc/r/bin/dsymutil -dump-debug-map /home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/inexistant 2>&1 | /tmp/_update_lc/r/bin/FileCheck /home/dave/ro_s/lp/llvm/test/tools/dsymutil/debug-map-parsing.test --check-prefix=NO-EXECUTABLE -- Exit Code: 1 Command Output (stderr): -- touch: cannot touch '/home/dave/ro_s/lp/llvm/test/tools/dsymutil/Inputs/basic.macho.x86_64.o': Read-only file system -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. ******************** Failed Tests (1): LLVM :: tools/dsymutil/debug-map-parsing.test
As also reported at https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20210118/872711.html "Re: [llvm] 48d2068 - [dsymutil] Warn on timestmap mismatch between object file and debug map" about the re-revert https://github.com/llvm/llvm-project/commit/48d2068fb738302b9fba91c9bf8e4b051c3909eb "[dsymutil] Warn on timestmap mismatch between object file and debug map" (but for which there appears to be no Phabricator review of its own):
I have no idea what this warning is all about, and what exactly triggers it, but it looks like it breaks the
# Check if the C compiler supports the "visibility" function attribute # If supported, defines HAVE_FUNC_ATTRIBUTE_VISIBILITY AX_GCC_FUNC_ATTRIBUTE(visibility)
configure check used by Little-CMS (https://github.com/mm2/Little-CMS/blob/a0fc38ddd55a0341dafa7414ac624c1f09271401/configure.ac#L70; e.g. built as part of building LibreOffice), when building on macOS:
configure:15908: checking for __attribute__((visibility)) configure:15930: /Users/stephan/Software/llvm/inst/bin/clang -m64 -mmacosx-version-min=10.15 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -fno-sanitize-recover=all -ferror-limit=0 -o conftest -ggdb2 -Xclang -debug-info-kind=constructor -O0 -fstrict-aliasing -fstrict-overflow -I/Users/stephan/Software/lo/core/include -I/Users/stephan/Software/adoptopenjdk.net/OpenJDK15U-jdk_x64_mac_hotspot_15.0.1_9/jdk-15.0.1+9/Contents/Home/include -I/Users/stephan/Software/adoptopenjdk.net/OpenJDK15U-jdk_x64_mac_hotspot_15.0.1_9/jdk-15.0.1+9/Contents/Home/include/darwin conftest.c >&5 warning: /Users/stephan/Software/lo/TMPDIR/conftest-01e065.o: timestamp mismatch between object file (2021-01-18 19:22:51.045749227) and debug map (2021-01-18 19:22:51.000000000) warning: /Users/stephan/Software/lo/TMPDIR/conftest-01e065.o: timestamp mismatch between object file (2021-01-18 19:22:51.045749227) and debug map (2021-01-18 19:22:51.000000000) configure:15930: $? = 0 configure:15943: result: no
That is, the warning output apparently confuses the AX_GCC_FUNC_ATTRIBUTE logic and makes it erroneously assume that Clang does not support attribute((visibility)).
Seems like a mismatch in precision between the timestamp in the debug map and the one return from the filesystem. I don't think we need that much precision so i'll truncate it to seconds.
If I'm reading this right, we are warning for archive members (where the timestamp is used to disambiguate between same-named objects in different slices) only in verbose mode and here always? I would have expected it to be the other way round or at least consistent between the two.