Open i-ilak opened 3 months ago
bkryza
commented
3 months ago @i-ilak I will look into this, but first I'll have to setup this toolchain on my machine and try to reproduce.
Have you tried to run clang-tidy on your codebase with your compile_commands.json - does it work or do you also get similar errors?
If it does work, then there must be a way to make clang-uml work with this...
i-ilak
commented
3 months ago @bkryza Unfortunately I dont have the container open anymore… I will reproduce it tomorrow and try clang-tidy and let you know how it goes!
Thanks for the help!
andylinpersonal
commented
3 months ago Hi @bkryza and @i-ilak:
I've found a workaround to make clang-uml happy with xtensa-esp32s3-elf and maybe for the
xtensa-esp32-elf, similarily. This issue may root in the upstream clang frontend, which doesn't know the customized xtensa target triple reported by xtensa-esp*-elf-g++ ...
xtensa-esp32s3-elf-g++.wrapper and xtensa-esp32-elf-g++.wrapper
#!/bin/bash
__real_bin="$(basename "$0")"
# Remove the unknown target triple printed by xtensa-xxxxxx
{ "${__real_bin%.wrapper}" "$@"; } 2>&1 | grep -v 'Target: xtensa'.clang-uml
# /path/to/your/compile_commands.json, usually ./build
compilation_database_dir: build
output_directory: build/diagram
query_driver: xtensa-esp32s3-elf-g++.wrapper
# Or query_driver: xtensa-esp32-elf-g++.wrapper
add_compile_flags:
- '-m32'
- '-mllvm'
- '--mtriple=xtensa' # Make xtensa assembler work by manually specify the target triple
- '-D__XTENSA__=1'
- '-fparse-all-comments'
- '-fno-rtti'
- '-fno-exceptions'
- '-fms-extensions' # Allow to cast from void* to int
- '-Wno-int-to-void-pointer-cast'
remove_compile_flags:
- '-fno-shrink-wrap'
- '-mlongcalls'
- '-fstrict-volatile-bitfields'
- '-fno-tree-switch-conversion'
- '-Wno-old-style-declaration'
- '-Werror=all'
- '-pedantic'
- '-nostartfiles'
diagrams:
# your_diagram: ...And invoke clang-uml with:
PATH="$PATH:/path/to/dirname/of/xtensa-YOUR_XTENSA_TARGET-elf-g++.dummy" clang-umlTested with latest (2c236271543da302134a608021f1630535af3d92) clang-18-based build on an Ubuntu machine.
Have fun :smile:
i-ilak
commented
3 months ago @bkryza I tried running clang-tidy but this does not really work since clang-tidy has no --query-driver feature.
I also tried @andylinpersonal approach. First of all, thanks for taking the time to comment! Doing this removes all errors but calng-uml crashes with a Segmentation fault (Core dumped). Unfortunately I couldn't test it yet with the newest version of clang-18 and clang-uml (I only have clang-15 installed on my machine). I will need to compile the llvm-18 and clang-uml 0.5.3 first to test the above with the newest versions...
bkryza
commented
3 months ago @i-ilak If clang-uml crashes with segmentation fault it's likely to be a bug in clang-uml itself. Are you able to build clang-uml from source? If yes, please try to build it in debug mode:
cd clang-uml
make debug
debug/src/clang-uml ...It should print a stack trace in your terminal after segfault...
andylinpersonal
commented
3 months ago Hi @i-ilak: I encountered similar segfaults previously. I've tried to put fewer files into clang-uml and the spurious (?) segfaults disappeared. Dunno the exact reason of crashes.
i-ilak
commented
3 months ago Hi @andylinpersonal
Im glad you are saying this b.c. I thought I might be crazy. I build clang-uml with clang-18 in debug mode and rerun everything and no segfault now.
Output of clang-uml --version in Debug mode.
clang-uml 0.5.3-1-g2c23627
Copyright (C) 2021-2024 Bartek Kryza <bkryza@gmail.com>
Linux x86_64 5.15.0-107-generic
Built against LLVM/Clang libraries version: 18.1.8
Using LLVM/Clang libraries version: Ubuntu clang version 18.1.8 (++20240615103753+3b5b5c1ec4a3-1~exp1~20240615223858.136)@bkryza Im not sure I can reproduce it in Debug mode... With the current debug build clang-uml works just fine with the xtensa toolchain...
bkryza
commented
3 months ago @i-lak One difference I see is that the debug version you've built is linked with LLVM 18, while in the first post you had clang-uml linked against LLVM 16. Can you try to build release in the same clang-uml folder:
make releaseand check if it's linked with LLVM 18 and whether it crashes or not...
andylinpersonal
commented
3 months ago Hi @bkryza: BTW, could you please add the backtrace as a dedicated build option? Just like the following snippet:
option(CLANG_UML_ENABLE_BACKTRACE "" OFF)
if(LINUX AND (CMAKE_BUILD_TYPE MATCHES Debug OR ${CLANG_UML_ENABLE_BACKTRACE}))
# ...@andylinpersonal I've added that option, you can now build like:
CLANG_UML_ENABLE_BACKTRACE=OFF make releaseHowever bear in mind that in release mode you'll only get the function/method names in the backtrace at best (unless they were inlined), and not the exact line of code that caused a crash...
Setup & problem
I have a project that was compiled with
platformiofor aesp32board, i.e. it uses thextensa-esp32-elf-g++toolchain. I apologise in advance, but since Im usingplatformioto generate my project, creating a simple example to reproduce the issue is a bit tricky (i.e. it for sure doable, I just need to write theCMakeLists.txtfile to cross-compile one of your examples with the given toolchain). I will try do so in the coming day, but it might not be possible to do what I want for some more general reason, so I thought I ask before spending the time to create the example.Configuration & error
Im trying to generate the class diagrams with the following configuration file:
When I run the command
I get the following error:
The core issue seems to be
Adding a variation of
-arch/triple xtensa/xtensa-esp32-elfto theadd_compile_flagsentry did not work, so Im not entirely clear if I just not correctly configuring this, or ifclang-umldoes not support that compiler...So, do you think it should in principle be possible to create a UML-graph given this toolchain?
clang-umlversionAccording to this article
clang-16should supportxtensabackend...