[xtensa] why keeping old HAL files instead of pulling it from the xtensa tools install ?

[williamtcdns]

Xtensa HAL found at:
https://github.com/zephyrproject-rtos/hal_xtensa

exist in the xtensa tools install at:

./tools/RJ-2024.3-linux/XtensaTools/xtensa-elf/include/
./tools/RJ-2024.3-linux/XtensaTools/xtensa-elf/src/hal/
./builds/RJ-2024.3-linux/sample_controller/xtensa-elf/arch/include/xtensa/config/

Why not use files in the xtensa tools install instead of keeping an old copy at https://github.com/zephyrproject-rtos/hal_xtensa which does not build with recent xtensa tools ?

[williamtcdns]

Hi @henrikbrixandersen , could you help me direct this question to the proper channel or xtensa people ?

[henrikbrixandersen]

Hi @henrikbrixandersen , could you help me direct this question to the proper channel or xtensa people ?

Ping @dcpleung, @andyross, @nashif

[dcpleung]

Errr... because if you build with Xtensa tools, hal_xtensa is not being used. And all those files are only used when building with GCC toolchains.

[williamtcdns]

I am building with Xtensa tools, more precisely RJ-2024.3 which uses clang; hal_xtensa appears to be needed; I had to manually updates hal_xtensa files for things to build and run.

I am at least glad to know that hal_xtensa is only used when building with GCC.

Could you please advise what I might be missing which is causing hal_xtensa to be needed ?

[dcpleung]

The compiler should insert its own search path before anything else so the HAL that is bundled with the toolchain package will be used instead.

Without access to your toolchain and a way to reproduce the issue, there is not much we can do to help.

[williamtcdns]

Including @arnabcdns to this discussion...

I am successfully able to build and run with RJ-2024.3 when I delete the hal_xtensa folder from modules.
xt-clang is not inserting its own search path before anything else as shown by the option -v when given to xt-clang.
Deleting the hal_xtensa folder from modules before building removes following include search paths which was causing failures:

	-I/home/williamt/zephyrproject8/modules/hal/xtensa/include
	-I/home/williamt/zephyrproject8/modules/hal/xtensa/XTENSA_HAL
	-I/home/williamt/zephyrproject8/modules/hal/xtensa/zephyr/soc/sample_controller

Since xt-clang is not inserting its own search path before anything else, the removal of above search paths effectively makes xt-clangs use the HAL that is bundled with Xtensa toolchain.

Is there a cleaner way to prevent the use of the module hal_xtensa when using xt-clang without having to remind that it needs to be manually deleted ?

[dcpleung]

#77947

[andyross]

Coming by: note that the upstream llvm/clang work by Espressif doesn't include the HAL files at all, as it builds a single compiler for all Xtensa targets. I've had some success getting Zephyr to build and run with this compiler (and need to upstream the patches), so the need for the platform headers is going to be present long term regardless.

If newer Cadence tools don't like these being on the include path at all, then please file a bug and/or submit a patch to the cmake integration to remove them when ZEPHYR_TOOLCHAIN_VARIANT=xt-clang