Crash in Clang: Unexpected Xtensa GCC toolchain version (LLVM-160)

[aykevl]

I got this crash with assertions enabled:

Unexpected Xtensa GCC toolchain version
UNREACHABLE executed at /home/ayke/src/github.com/tinygo-org/tinygo/llvm-project/clang/lib/Driver/ToolChains/Xtensa.cpp:41!
libclang: crash detected during parsing: {
  'source_filename' : 'extra.go!cgo.c'
  'command_line_args' : ['clang', '-D_FORTIFY_SOURCE=0', '-Werror', '-fshort-enums', '-Wno-macro-redefined', '-fno-exceptions', '-fno-unwind-tables', '-fno-asynchronous-unwind-tables', '-ffunction-sections', '-fdata-sections', '--sysroot=/home/ayke/.cache/tinygo/picolibc-xtensa-esp32', '-isystem', '/home/ayke/src/github.com/tinygo-org/tinygo/lib/picolibc/newlib/libc/include', '-isystem', '/home/ayke/src/github.com/tinygo-org/tinygo/lib/picolibc/newlib/libc/tinystdio', '-g', '-Oz', '--target=xtensa', '-mcpu=esp32', '-I/home/ayke/src/github.com/tinygo-org/tinygo/testdata/cgo', '-DSOME_CONSTANT=17', '-isystem', '/home/ayke/src/github.com/tinygo-org/tinygo/llvm-project/clang/lib/Headers'],
  'unsaved_files' : [('extra.go!cgo.c', '...', 551)],
  'options' : 1,
}

This is the relevant code:

  if (!GCCInstallation.isValid()) {
    llvm_unreachable("Unexpected Xtensa GCC toolchain version");
  }

I did not yet investigate this further or create a small reproducer. Will hopefully do that soon.

[aykevl]

Here is a reproducer in Python (adjust paths as needed and make sure foobar.c exists):

#!/usr/bin/env python3

filename     = 'foobar.c'
libclangfile = './llvm-build/lib/libclang.so'

from ctypes import *

# Load the .so file
clang = cdll.LoadLibrary(libclangfile)

# Create an index
clang.clang_createIndex.restype = POINTER(c_size_t)
index = clang.clang_createIndex(0, 0)

# Construct command line argument list
args = [filename.encode(), b'--target=xtensa']
argsArrayType = c_char_p * len(args)
argsArray = argsArrayType(*args)

# parse the file
unit = c_void_p()
errCode = clang.clang_parseTranslationUnit2(
        index,
        None,
        argsArray, len(args), # command line args
        None, 0,              # unsaved files
        0,                    # options
        pointer(unit))
if errCode != 0:
    raise ValueError('clang_parseTranslationUnit2 returned error code %d' % errCode)

print('successfully parsed', filename)

For ARM, it works well:

$ ./xtensa-libclang.py
successfully parsed foobar.c

For Xtensa, it does not:

$ ./xtensa-libclang.py
Unexpected Xtensa GCC toolchain version
UNREACHABLE executed at /home/ayke/src/github.com/tinygo-org/tinygo/llvm-project/clang/lib/Driver/ToolChains/Xtensa.cpp:41!
libclang: crash detected during parsing: {
  'source_filename' : '(null)'
  'command_line_args' : ['clang', 'foobar.c', '--target=xtensa'],
  'unsaved_files' : [],
  'options' : 0,
}
Traceback (most recent call last):
  File "/home/ayke/src/github.com/tinygo-org/tinygo/./xtensa-libclang.py", line 30, in <module>
    raise ValueError('clang_parseTranslationUnit2 returned error code %d' % errCode)
ValueError: clang_parseTranslationUnit2 returned error code 2

[aykevl]

Actually it's way easier: any compilation triggers this bug:

$ llvm-build/bin/clang -o foobar.o tmp/foobar.c -c --target=xtensa
Unexpected Xtensa GCC toolchain version
UNREACHABLE executed at /home/ayke/src/github.com/tinygo-org/tinygo/llvm-project/clang/lib/Driver/ToolChains/Xtensa.cpp:41!
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: llvm-build/bin/clang -o foobar.o tmp/foobar.c -c --target=xtensa
1.      Compilation construction
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
llvm-build/bin/clang(+0x2ae7500)[0x56494071a500]
llvm-build/bin/clang(+0x2ae4e3e)[0x564940717e3e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f8e28d92140]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f8e288c3ce1]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7f8e288ad537]
llvm-build/bin/clang(+0x2a43fba)[0x564940676fba]
llvm-build/bin/clang(+0x3407af0)[0x56494103aaf0]
llvm-build/bin/clang(_ZNK5clang6driver6Driver12getToolChainERKN4llvm3opt7ArgListERKNS2_6TripleE+0x5db)[0x564940ef8eab]
llvm-build/bin/clang(_ZN5clang6driver6Driver16BuildCompilationEN4llvm8ArrayRefIPKcEE+0x1071)[0x564940f03161]
llvm-build/bin/clang(main+0xce9)[0x56493eb4e0a9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f8e288aed0a]
llvm-build/bin/clang(_start+0x2a)[0x56493ebd195a]
fish: “llvm-build/bin/clang -o foobar.…” terminated by signal SIGABRT (Abort)

I think it would be more reasonable to continue without a GCC installation instead of crashing.

[aykevl]

Oops, I forgot I was on a different branch: gerekon/xtensa-lld_update (2b94f6d). So I think that branch has a bug, but it's not in the xtensa_release_13.0.0 branch.
Feel free to close this issue.

[aykevl]

After building LLVM 14 (#57) I found that this bug is present in the xtensa_release_14.0.0 branch:

$ llvm-build/bin/clang -c -o tmp/test.o -Os tmp/test.c --target=xtensa
Unexpected Xtensa GCC toolchain version
UNREACHABLE executed at /home/ayke/src/github.com/tinygo-org/tinygo/llvm-project/clang/lib/Driver/ToolChains/Xtensa.cpp:42!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: llvm-build/bin/clang -c -o tmp/test.o -Os tmp/test.c --target=xtensa
1.      Compilation construction
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
llvm-build/bin/clang(+0x2af3510)[0x55daa932b510]
llvm-build/bin/clang(+0x2af0cce)[0x55daa9328cce]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140)[0x7f8868017140]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x141)[0x7f8867b48ce1]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x123)[0x7f8867b32537]
llvm-build/bin/clang(+0x2a3787a)[0x55daa926f87a]
llvm-build/bin/clang(+0x3495845)[0x55daa9ccd845]
llvm-build/bin/clang(_ZNK5clang6driver6Driver12getToolChainERKN4llvm3opt7ArgListERKNS2_6TripleE+0x5ca)[0x55daa9b7629a]
llvm-build/bin/clang(_ZN5clang6driver6Driver16BuildCompilationEN4llvm8ArrayRefIPKcEE+0x1077)[0x55daa9b81337]
llvm-build/bin/clang(main+0xee4)[0x55daa75bf2e4]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f8867b33d0a]
llvm-build/bin/clang(_start+0x2a)[0x55daa7647e6a]

This is a blocker for LLVM 14 support in TinyGo, unless we drop support for Xtensa. TinyGo doesn't need a GCC installation, we bring our own version of the C standard library for example.
Also, using llvm_unreachable is not a correct way to handle this error. It should only be used for invariants, not for things that can actually happen in practice (in release mode with assertions disabled, it will be equivalent to __builtin_unreachable()).

[andreisfr]

Hi @aykevl, could I ask you to describe structure of the sysroot directory:

'--sysroot=/home/ayke/.cache/tinygo/picolibc-xtensa-esp32
?
We have fix of this issue for small examples, but could you add some instructions to reproduce toolchain environment with TinyGo application from your first comment for testing purposes?

[aykevl]

Here is the sysroot I'm using: sysroot.zip
Command:

../llvm-build/bin/clang -Werror -fshort-enums -Wno-macro-redefined -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -ffunction-sections -fdata-sections --sysroot=sysroot-picolibc-xtensa-esp32 -g -Oz --target=xtensa -mcpu=esp32 -c -o test.o test.c

The file test.c doesn't really matter, but for completeness here it is:

int foo(void) {
    return 3;
}

The main reason to set the sysroot is for a consistent environment. Include directories (including the include directory in the sysroot) can be manually provided (see tinygo-org/tinygo#2781 for example).

[andreisfr]

Hi, @aykevl , thank you for answer. I have a question about "sysroot-picolibc-xtensa-esp32" directory structure. If I understand correctly, usually gcc compiler expects that sysroot directory contains include and lib subdirectories, something like that:
sysroot-picolibc-xtensa-esp32/include
sysroot-picolibc-xtensa-esp32/lib
I'm not sure whether "sysroot-picolibc-xtensa-esp32/lib.a" library will be found by gcc. What do you think?

[andreisfr]

Hi, @aykevl , please check latest version of the default branch

[gerekon]

Closed by cebbe2d