Vscode-cpptools: avr-gcc -mmcu command is omitted. -MF arg should be stripped

[patrykbajos]

Type: LanguageService

Describe the bug

• OS and Version: Linux x64 4.14
• VS Code Version: 1.31.1
• C/C++ Extension Version: 0.21.0
• Other extensions you installed (and if the issue persists after disabling them): vector-of-bool.cmake-tools, cheshirekow.cmake-format, platformio.platformio-ide
• A clear and concise description of what the bug is.

Processor specific command -mmcu=atmegaXX is not recognized properly.
https://www.microchip.com/webdoc/AVRLibcReferenceManual/using_tools_1using_avr_gcc_mach_opt.html
None of these macros are not present in IntelliSense.

To Reproduce

1. Make compile_commands.json for example:

[
    {
        "arguments": {
            "/usr/bin/avr-gcc",
            "-mmcu=atmega16",
            "-DF_CPU=1000000",
            "-c",
            "-o",
            ".../build/main.o",
            ".../src/main.c",
         },
        "directory": ".../src",
        "file": ".../src/main.c"
    }
]

1. Add it to your configuration compileCommands.
2. Try to check IntelliSense in any of files contined in your compileCommands..
3. F_CPU macro is recognized, hardware specific macros are not.

Expected behavior

I expect to have hardware specific defines such as __AVR_ATmega16__.
I expect to have properly recognized avr/io.h header. It is not because lack of define __AVR_ATmega16__.

Screenshots

Additional context

[sean-mcmanus]

This appears to be the same issue as https://github.com/Microsoft/vscode-cpptools/issues/1755 .The current workaround is to set your compilerPath to "/usr/bin/avr-gcc -mmcu=...". Does that work for you? Or does it appear that our attempt to query the /usr/bin/avr-gcc is failing?

[patrykbajos]

I have tried /usr/bin/avr-gcc -mmcu=... (before posting Issue) as compilerPath. It was not working.

{
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}",
                "${currentIncludes}"
            ],
            "defines": [],
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "${workspaceFolder}"
                ],
                "limitSymbolsToIncludedHeaders": true
            },
            "compilerPath": "/usr/bin/avr-gcc -mmcu=atmega16",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "compileCommands": "/home/patryk/Projects/ModularOS/compile-commands.json"
        }

Here is my configuration I am using. Compile command for file that I am testing is:

{
        "arguments": [
            "/usr/bin/avr-gcc",
            "-DNDEBUG",
            "-Os",
            "-I/home/patryk/Projects/ModularOS/modularos-core",
            "-I/home/patryk/Projects/ModularOS/modularos-usart",
            "-mmcu=atmega16",
            "-DF_CPU=16000000",
            "-c",
            "-o",
            "/home/patryk/Projects/ModularOS/build/release/obj_modularos-core_atmega16_16000000/modularos-core/system.o",
            "/home/patryk/Projects/ModularOS/modularos-core/modularos-core/system.c"
        ],
        "file": "/home/patryk/Projects/ModularOS/modularos-core/modularos-core/system.c",
        "directory": "/home/patryk/Projects/ModularOS"
    },

There are only defines like __AVR__ which are not specific to -mmcu=....

[bobbrow]

Did you try with the 0.22.0-insiders build? There was a bug in the current release version of the extension where compilerPath did not override the compiler in compile_commands.json.

[patrykbajos]

@bobbrow I have tested 0.22.0-insiders and defines are working as it should. -mmcu= in compile_commands.json is still not working but it works with use of compilerPath.

[bobbrow]

This may be fixed with 0.29.0 (which is not released yet). We added support for more args in compile_commands.json.

[sean-mcmanus]

Is this fixed with 0.29.0?

[MrMartin92]

For me it is still not working.

Here is a sample source file I created for testing. You can see the section with __AVR_DEVICE_NAME__ is not active and therefore all symbols like DDRD are missing. On the other hand __AVR__ is working fine. You can see I have installed version 0.29.0 on the left side.

Here is my compiler_commands.json which I generate with compiledb and make.

A quick look with avr-gcc -dM -E -mmcu=atmega328p shows that __AVR_DEVICE_NAME__ gets clearly defined.

So -mmcu=atmega328p gets still ignored.

[sean-mcmanus]

@Colengms Are you able to repro this? Or do we need more info?

[Colengms]

@patrykbajos @MrMartin92 , are either of you still seeing this issue? There have been some improvements to our compiler probing over the past several months. If you can still repro, can you enable debug logging using "C_Cpp.loggingLevel": "Debug", and provide the output of the C/C++ channel after repro'ing? That should now include the command line we used to probe the compiler for default includes and defines. (We should not be omitting the -mmcu arg, but other args we add or remove could be leading to an issue). Also, could you post the output of the C/C++: Log Diagnostics command? That should tell us exactly how we configured IntelliSense for the file.

[MrMartin92]

@Colengms
Yes I'm still seeing this issue with version 1.0.0 and 1.0.1-insiders.

Here are your requested log outputs. Unfortunately the debug log is in German. I tried to set everything to Englisch but it's still outputting in German. 🤔

The logs are from version 1.0.0.

• cpptools_debug.log
• cpptools_diagnostics.log

I will happily provide you more informations if needed.

[MrMartin92]

I tried to experiment a little bit with the compile_commands.json and got it working.

I had to remove all appending header files and added the full path to the compiler avr-gcc. Both is necessary or otherwise it is not working.

Old compile_commands.json:

[
 {
  "directory": "/home/tobias/projects/outdoor-sensor",
  "arguments": [
   "avr-gcc",
   "-c",
   "-mmcu=atmega328p",
   "-Os",
   "-MD",
   "-MP",
   "-MF",
   "build/dep/main.d",
   "-o",
   "build/obj/main.o",
   "src/main.c",
   "/usr/avr/include/avr/io.h",
   "/usr/avr/include/avr/sfr_defs.h",
   "/usr/avr/include/inttypes.h",
   "/usr/lib/gcc/avr/10.2.0/include/stdint.h",
   "/usr/avr/include/stdint.h",
   "/usr/avr/include/avr/iom328p.h",
   "/usr/avr/include/avr/portpins.h",
   "/usr/avr/include/avr/common.h",
   "/usr/avr/include/avr/version.h",
   "/usr/avr/include/avr/fuse.h",
   "/usr/avr/include/avr/lock.h",
   "/usr/avr/include/util/delay.h",
   "/usr/avr/include/util/delay_basic.h",
   "/usr/avr/include/math.h"
  ],
  "file": "src/main.c"
 }
]

New working compile_commands.json:

[
 {
  "directory": "/home/tobias/projects/outdoor-sensor",
  "arguments": [
   "/usr/bin/avr-gcc",
   "-c",
   "-mmcu=atmega328p",
   "-Os",
   "-MD",
   "-MP",
   "-MF",
   "build/dep/main.d",
   "-o",
   "build/obj/main.o",
   "src/main.c"
  ],
  "file": "src/main.c"
 }
]

Here are the log outputs with the working compile_commands.json.

• cpptools_debug.log
• cpptools_diagnostics.log
  EDIT 1: I accidentally uploaded the previous logs 🙄~I will upload the right one soon when I find some time.~
  EDIT 2: Here are the correct one.
  cpptools_debug.log
  cpptools_diagnostics.log

[Colengms]

Thanks @MrMartin92 . Is this compiler executable in the current env path? If not, it would makes sense that it would need to be provided in compile_commands.json. But, it sounds like it's failing to parse additional source (header) file paths on the command line for some reason. I'll look into that.

[MrMartin92]

Is this compiler executable in the current env path?

Yes. The folder which contains the compiler is in the env path. I can also execute the compiler from the terminal without the full path.

[Colengms]

Hi @MrMartin92 . I created a new issue to track what I suspect you are seeing. It looks like our logic to validate the compiler path does not take the environment paths into consideration. You repro logs indicate you are falling back to the base configuration early, before even attempting to probe the compiler with the args, which would seem to point to the compiler path. We will add some better logging around this scenario.

I'm not able to repro an issue with headers as compiler args, unless the files do not actually exist at the paths I'm specifying. I could take a closer look at that, if you could send me logs from a repro in which the compiler path is not the cause.

[MrMartin92]

Hi, @Colengms and sorry for the late response. I switched to bear that's why forgot about this issue.

I tested it again with version 1.1.0 and your fix #6179, which is working great by the way.

The following logs are with a compile_commands.json generated with bear. This is working perfectly.
cpptools_diagnostics.log
cpptools_debug.log

But when I use compiledb to generate my compile_commands.json it fails.
cpptools_diagnostics.log
cpptools_debug.log

I also checked the present of all header files, and they are definitely present at their specified location.

[Colengms]

Hi @MrMartin92 I believe the issue is the -MF arg that we are not currently stripping from the compiler probe. That argument appears to be invalid if not accompanied by the source file (which we strip out). The command lines we used to probe the compiler are logged in the debug output. Could you confirm that is the only arg that needs to be removed to get a successful probe of the compiler?

I'll use this bug to track stripping out of the -MF arg from the probe.

[MrMartin92]

Hi @Colengms,
I can't confirm that. I removed just -MF and the file path for the .d file (I tested it also with the .d file path present and just removing -MF, no difference). And the problem still occurs.

cpptools_diagnostics.log
cpptools_debug.log

But I discovered that I have to remove exactly three appended header files to get it working. If only one is referenced it fails again.

"/usr/avr/include/avr/fuse.h",
"/usr/avr/include/avr/iom328p.h",
"/usr/avr/include/avr/portpins.h",

You can see here -MF is still present and it is working. I just removed the 3 file paths.

cpptools_diagnostics_fixed.log
cpptools_debug_fixed.log

As I mentioned before, these files exist. (I just append .txt to be able to upload these here.)

fuse.h
iom328p.h
portpins.h

[MrMartin92]

All three files have in common, that _AVR_IO_H_ gets checked if it is defined. If it is not defined a error (#error "You must #include <avr/io.h> and not <avr/fuse.h> by itself.") is generated. Could it be possible that _AVR_IO_H_ is not defined while probing and therefore the #error hinders the probing?

EDIT:
I removed all _AVR_IO_H_ checks to test my theory and indeed, now it is working! Maybe it's not good to append all header files into the compile_commands.json like compiledb did?

[Colengms]

Hi @MrMartin92 . As part of fix for this, we will also strip any input file arguments (any arg that refers to a file on disk, and not a continuation of the prior arg).

I'm going to move this issue to https://github.com/microsoft/vscode-cpptools/issues/6478 , and close this one as I believe the original issue has been addressed.