Sorry, I’ve been meaning to reply to this for a bit.
- The tracing would be really helpful IMO if we decide we want to keep multiple search paths in the long run (being discussed in RFC: Time to drop legacy runtime paths? right now). If it’s not too much work to implement it seems worthwhile even if there’ll be no need for it in the long run though.
- We used to try the exact triple before the canonicalized one, before ⚙ D101194 [Driver] Push multiarch path setup to individual drivers changed that (and [Driver] Use normalized triples for per-target runtimes · llvm/llvm-project@36430d4 · GitHub refined the behavior). CC @phosek, who authored those patches.
- It might be nice to give users direct control over the runtime search path if they desire it, but in most cases it seems nicer for the user (at least to me) if Clang could do the right thing on its own without needing the additional argument.
One other option I didn’t see in your post would be to make the LLVM build install the runtimes to the normalized triple path instead of the triple as it was passed. That wouldn’t solve all issues (e.g. the version number problems from Handling version numbers in per-target runtime directories), but it would at least make the install path logic match Clang’s search logic and avoid e.g. the eabi issue you brought up.