[llvm] [MC][DWARF] Use target (non-native) path separators when building DWARF directory-tables (PR #115888)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> > Hrm :/ that seems a bit problematic... (since at compile time we can't know which OS you'll be remote debugging from) - would it be reasonable to always use path separators that match the target, and have consumers do remapping as needed?
> 
> I'd say so -- interpreting the "target" as the triple here, which is what this patch implements: when targeting the PS5 triple it uses windows path separators when constructing the linetable header, plus there's a flag for testing. Perhaps there's a gap in meaning between "target" and "triple" though?

Sorry, I'm not trying to draw a distinction between triple and target - I'm being a bit vague/loose with terminology there, probably.

So the choice of separator is target/triple motivated, but isn't necessarily the separator of that target/triple? Or would it be reasonable to say the path separator is, as far as LLVM's concerned, the separator for the target?

We currently don't have, so far as I can see, code to determine/answer the question of "what is the target's path separator" - we only have "real_style" which, given the "native" style, produces windows on Win32, and posix otherwise. But we could add something that gave a style given a triple, and could use that?

If you want to be able to reuse build artifacts, if the build for a given target should be about that target, not about the host - it seems like the right thing to do would be to have the path separators match the target - and a consumer could then rely on that and replace path separators with whatever path separators the local machine they're on is using?

Alternatively, I guess since DWARF contains absolute paths (well, can - you can avoid that with -fdebug-compilation-dir=. etc) - how could those paths be portable to another machine, let alone one with a different path separator/file system?

> I don't believe we're unique here, in a previous life doing embedded systems things I had a few proprietary connect-to-the-device debug adapters that were Windows only, but with Linux toolchains available too. Certainly not a common use case.



https://github.com/llvm/llvm-project/pull/115888