--query-driver does not follow symlinks

[UtkarshVerma]

I have a cross-compiled project where I was trying to get standard header path extraction to work. In my environment, arm-none-eabi-gcc is resolved by default to /usr/sbin/arm-none-eabi-gcc.

What I find weird is that clangd is able to resolve standard includes with --query-driver=/usr/*/arm-none-eabi-gcc but not with --query-driver=/usr/bin/arm-none-eabi-gcc.

[HighCommander4]

I have a cross-compiled project where I was trying to get standard header path extraction to work. In my environment, arm-none-eabi-gcc is resolved by default to /usr/sbin/arm-none-eabi-gcc.

What I find weird is that clangd is able to resolve standard includes with --query-driver=/usr/*/arm-none-eabi-gcc but not with --query-driver=/usr/bin/arm-none-eabi-gcc.

Did you mean to write /usr/sbin/arm-none-eabi-gcc there?

[UtkarshVerma]

No, I forgot to mention that /usr/sbin is symlinked to /usr/bin

[HighCommander4]

Ah, I see. Currently, the matching of the driver's path against the --query-driver pattern is purely string-based, with no filesystem operations like symbolic link resolution involved.

[UtkarshVerma]

Yeah, but that would explain if things didn't work out if I had passed /usr/sbin/arm-none-eabi-gcc as the query driver arg. However, in my case, passing /usr/bin/arm-none-eabi-gcc did not work. And weirdly, /usr/*/arm-none-eabi-gcc seems to work.

[HighCommander4]

Maybe I'm missing something, but your observations make sense to me: if your driver's actual path is /usr/sbin/arm-none-eabi-gcc, then:

• it matches the pattern /usr/sbin/arm-none-eabi-gcc
• it matches the pattern /usr/*/arm-none-eabi-gcc
• it does not match the pattern /usr/bin/arm-none-eabi-gcc

[UtkarshVerma]

Yes, I would like to confirm this as well:

• /usr/sbin -> /usr/bin
• arm-none-eabi-gcc is actually saved at /usr/bin
• Passing /usr/bin/arm-none-eabi-gcc does not work
• Passing /usr/sbin/arm-none-eabi-gcc or /usr/*/arm-none-eabi-gcc works
• My shell resolved arm-none-eabi-gcc to /usr/sbin/arm-none-eabi-gcc

I just wish to set a sensible and portable value to the query driver in my NVIM setup so that switching distros doesn't cause an issue in the future. What do you think I should put in the glob? And would it be possible to have a value which doesn't affect my non-embedded projects?

[HighCommander4]

As a vscode user, my approach is to specify --query-driver only on a per-project basis. I'll either just hard-code the path (no globs), or for a more portable approach, have the project's "configure" step or equivalent write the path to my project's .vscode/settings.json file.

[UtkarshVerma]

Oh, for NVIM, there's no such option. Would it not be possible to have this done through the .clangd file?

[HighCommander4]

Would it not be possible to have this done through the .clangd file?

It would be technically possible, but security-related considerations would have to be discussed. (Depending on the editor, it may open up new attack surfaces like "clone malicious repository, containing a malicious driver script whitelisted via query-driver in .clangd, leading to clangd executing the script".)

[HighCommander4]

Updated issue title to clarify that the issue is related to symlinks.

See also this comment from Sam:

symlinks and progra~1 mean normalization based on actual filesystem access, and choosing between multiple forms that are in some sense equally valid.

I don't think I'm opposed if someone wants to take a shot at solving that (we can afford to do IO here), but it's definitely a more complicated idea.