How to get rid of `unknown target` warning

Get help SonarCloud
#1

Hi,

I get warnings about unknown target:

WARN: /__w/OpenBikeSensorFirmware/OpenBikeSensorFirmware/src/utils/streams.cpp: unknown target "xtensa-esp32-elf", using "x86_64-unknown-unknown" instead
ERROR: unknown target triple 'xtensa-esp32-unknown-elf', please use -triple or -arch

Is there a way to get rid of this, or point to a better matching arch than “x86_64”?

Analysis is at https://github.com/openbikesensor/OpenBikeSensorFirmware/runs/1634753095?check_suite_focus=true ff.

Thanks,
Andreas.

#2

Hi @Andreas_Mandel,

no, currently there is no way to get rid of this nor to match it to a different arch. The only way to match it to another arch is to build for another arch.

That message doesn’t mean that files are not analyzed, however some rules related to size of types may raise some false positives.

#3

Hi Massimo,
thanks for the details. Is there a list of supported architectures? I’m not sure if, and how I can build with different target - but I will check.

There are some wired false positives and I thought they might be related. Like https://sonarcloud.io/project/issues?id=Friends-of-OpenBikeSensor_OpenBikeSensorFirmware&open=AXbKrd_f6OPCK4dylNqp where a used variable is flagged as unused or uninitialized https://sonarcloud.io/project/issues?id=Friends-of-OpenBikeSensor_OpenBikeSensorFirmware&open=AXY47yRRiMTN3SAGSh-1&resolutions=FALSE-POSITIVE

Kind regards, Andreas.

#4

Hi @Andreas_Mandel,

sorry for the delay.

as we are based on Clang we support Clang supported architectures.

Maybe but not sure it is the cause.

If you want you could try to set sonar.verbose=true property to enable debug logging during analysis and see if some errors occurs during analysis.

#5

Hi @mpaladin,
thanks for the feedback - no hurry. Thanks for your support!

I’ve added the the verbose option and it showed that some include files from external libraries had not been found. It was due to the sed modifications in the build-wrapper-dump.json. Now I do

sed -i 's|OpenBikeSensorFirmware/bin|OpenBikeSensorFirmware|g' \
     sonarqube-out/build-wrapper-dump.json
sed -i 's|\.pio/|bin/.pio/|g' \
        sonarqube-out/build-wrapper-dump.json

and the header file is found - at least there are no complaints any more in the verbose log. And the strange false positives vanished. :tada:

I also tried to replace xtensa-esp32-elf with le32-unknown-nacl in the build-wrapper-dump.json but with no luck - I assume the target arch is not detected via information from the build-wrapper-dump.json?

Kind regards, Andreas.

#6

Hi @Andreas_Mandel,

great!

We take the target from the gcc you are using, when you run the gcc compiler you are using with -v option you can see in the output something like:

Target: x86_64-apple-darwin19

We take the architecture from there.

#7

Hi Massimo,

thanks again for the details. Easy would be to be able to set the arch via property. :wink:

Based on your input, I’ve created a fake c++ that calls the original compiler but modifies the output of the Target to le32-unknown-nacl. The script is here https://github.com/openbikesensor/OpenBikeSensorFirmware/blob/master/.github/fake-cc and the sed line that causes SQ to use the fake-cc as compiler is:

# replace gcc with our script that reports the fake arch "le32-unknown-nacl"
sed -i "s|/github/home/.platformio/packages/toolchain-xtensa32/bin/xtensa-esp32-elf-g..|`pwd`/.github/fake-cc|g" \
    sonarqube-out/build-wrapper-dump.json

All can be found in out GitHub action at https://github.com/openbikesensor/OpenBikeSensorFirmware/blob/master/.github/workflows/ci.yml

Kind regards,
Andreas.

#8

Hi @Andreas_Mandel,

it is not easy to choose what should be configurable by property and at the same time avoid misuse of the product.

Not ideal workaround but I can understand, did you get the intended result?

#9

Yes it helped. Warnings are gone, results look, like the size of the types is now detected correctly.
There is now one complaint remaining in the logs, about one file missing: stdbool.h. I can not find it either - it seems all OK anyway.

Kind regards, Andreas.

#10

Ok, thank you for the update.