Attempting this after @thakis's comment: https://reviews.llvm.org/D98395#2639561
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
510 ms | x64 windows > lld.MachO::stabs.s |
Event Timeline
Something weird seems to be happening with the escaping of slashes on the Windows command line... @thakis, any idea why that might happen?
Maybe using %/t (see https://llvm.org/docs/CommandGuide/lit.html#substitutions) in the test could work?
IIRC backslashes doesn't work great with the -D FileCheck due to lit not knowing what the right escape level is. I vaguely remember hitting this somewhere not too long ago. I can't remember what I did about it though :/
lld/MachO/SyntheticSections.cpp | ||
---|---|---|
632 | Hm, it assumes that the source was compiled with a mach-o triple. Clang hopefully uses slashes when targeting mach-o even on Windows -- if not, that's a bug, right? The host machine shouldn't leak into the target machine. And assuming mach-o slashiness in a mach-o linker seems sensible. So this change here looks good to me, just the FIXME doesn't. |
Something weird seems to be happening with the escaping of slashes on the Windows command line
I think that's actually a red herring, it's just an artifact of how llvm-lit is printing out stuff. The reason the paths don't match is that lib/Object/Archive.h isn't using the host path separators, so we end up with a mixture of "/" and "\" on Windows. Didn't get around to pinpointing the exact function responsible though.
lld/MachO/SyntheticSections.cpp | ||
---|---|---|
632 | I guess it depends if we think the main use case after for linking Mach-O on Windows is to do remote debugging or to copy all the files (source and all) to the target machine. I think remote debugging is more likely, in which case the change here is probably wrong... |
Maybe using %/t (see https://llvm.org/docs/CommandGuide/lit.html#substitutions) in the test could work?
Ah yeah I stumbled across this yesterday... but due to the aforementioned mixed-separator issue it doesn't solve things.
Hm, it assumes that the source was compiled with a mach-o triple. Clang hopefully uses slashes when targeting mach-o even on Windows -- if not, that's a bug, right? The host machine shouldn't leak into the target machine. And assuming mach-o slashiness in a mach-o linker seems sensible. So this change here looks good to me, just the FIXME doesn't.