New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No avr-g++ support #528
Comments
Can you try This will attempt to extract them, unfortunately it's off by default for security reasons. |
That works perfectly! Any idea though how this could be done better? Perhaps a general option "I know what I'm doing, trust all compilers I specify" ;) In general I think, that avr-g++ and avr-gcc could be added to the list by default, they are safe to use. |
I guess, I was a little bit to fast with saying it works. It does in deed find the headers like "avr/io.h" , but there are a couple of problems: Clangd doesn't process these files correctly. When I jump into io.h for instance, it says it's not part of the compilation database ... while this is correct technically, I would that included files would kinda inherit the arguments? Secondly, things like "PORTD" are still not recogniced.
When incluing <avr/iom328p.h>, it is found. So either this is part of the first issue (clangd is not analyzing io.h) or "AVR_ATmega328P" is not set. Or possibly both. The third issue I have is that the special keyword "EEMEM" is not regognized, it's for declaring EEPROM variables. Thanks! |
I recommend specifying the CDB directory explicitly with the |
@HighCommander4 The issues I have are: Some macros are not set, leading to a few different issues. Any suggestions? |
If you don't pass
I think some of the remaining issues may be related to the fact that clang does not pick up the compiler's pre-defined macros (something I just discovered recently). I'm not sure how to work around that, sorry. |
Would you ever want that?
I think so too. Is there already an issue tracking that? As a workaround: Is it possible to tell clangd what macros it should use? I might could find out what avr uses and set it manually, not pretty but better than nothing I guess. |
You can get a list of macros with the following command:
The value for mmcu should be taken from the CDB |
There are a few issues here:
I filed #533 for it.
With clangd 11, you can use the config mechanism to automatically add flags of the form |
It might also be worth keeping https://github.com/llvm/llvm-project/blob/master/clang/lib/Basic/Targets/AVR.cpp#L298 up to date with new AVR toolchains. I suppose the only problem is there's no one maintaining it. |
@kadircet I just saw that the linked code seems to set the correct macro for the mcu (which would be in my case the atmega168p). But as you can see from my above screenshots this doesn't seem to be the case (device type not found). But I actually did have a look again: And it is actually found today and all my other issues described above are resolved as well?! I had a look and all my issues had to do with missing macros (including the missing "keyword" EEMEN, which turned out to be a macro as well from eeprom.h). So what happened? Why is this magically working now, even though I still use the same clang version (afaik)? |
I just had a look on my other machine and I still have the problem there. But it seems like there, the target "avr" is not picked up (which would explain a lot)
I don't get though why the target is not picked up though? It's the same code as on my other machine, the same CDB, the same arguments passed to clangd, the same clang and clang version (10.0.1), almost the same avr-g++ version (10.2.0 vs 10.2.1). And I use the same vscode-clangd extension (version 1.7.0). The only difference I see is that it's a different Linux distro (this is open suse, the other one arch linux) and I use here VsCodium (but I installed the latest version of the vscode extension from the vs code marketplace) Any ideas what happened here? |
I am not sure, my first guess would be about these two having a different clangd version but according to your explanation that doesn't seem to be the case. Could you share full clangd logs from both machines? Especially while passing |
Working
Broken
I used the same code on both my machine with the same CDB. Clang and clangd are both 10.0.1 The difference seems to be in this line |
so the only bugging thing i notice is, there's the mention of But this doesn't explain why the |
Ah I see, here is the correct output form the working one (where I changed the CDB accordingly)
The output of the command is |
Right, that's as I've feared. For some reason the clangd binary you are using on the "broken machine" is linked without avr support. You might want to file a bug against your distribution package maintainer. In the meantime you can try:
|
Just adding to this: I'm using (clangd 11.1.0) a
because that's not picked up from the (CMake generated) |
Awesome! This works! But one has to consider that |
Hi,
I tried to use clangd with my avr project using the avr-g++ compiler. The compile_command.json generated by cmake looks like this:
but clangd doesn't find the avr libraries such as <avr/boot.h>. Also Port numbers are now known and other problems.
So it seems like clangd doesn't get the implicit include files from avr-g++?
The text was updated successfully, but these errors were encountered: