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

aykevl · 2022-04-14T18:09:55Z

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.

The text was updated successfully, but these errors were encountered:

aykevl · 2022-04-14T20:01:49Z

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 · 2022-04-14T20:18:36Z

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 · 2022-04-15T00:32:03Z

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 · 2022-04-20T21:26:19Z

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 · 2022-05-19T08:57:34Z

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 · 2022-05-21T14:25:00Z

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 · 2022-05-24T09:40:40Z

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 · 2022-07-03T11:29:20Z

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

gerekon · 2022-09-24T11:29:11Z

Closed by cebbe2d

github-actions bot changed the title ~~Crash in libclang: Unexpected Xtensa GCC toolchain version~~ Crash in libclang: Unexpected Xtensa GCC toolchain version (LLVM-160) Apr 14, 2022

aykevl changed the title ~~Crash in libclang: Unexpected Xtensa GCC toolchain version (LLVM-160)~~ Crash in Clang: Unexpected Xtensa GCC toolchain version (LLVM-160) Apr 14, 2022

aykevl mentioned this issue Apr 20, 2022

[Xtensa] Fix crash when invoking Clang with assertions enabled (LLVM-162) #59

Open

gerekon closed this as completed Sep 24, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

aykevl commented Apr 14, 2022 •

edited

Loading

aykevl commented Apr 14, 2022 •

edited

Loading

aykevl commented Apr 14, 2022

aykevl commented Apr 15, 2022

aykevl commented Apr 20, 2022 •

edited

Loading

andreisfr commented May 19, 2022

aykevl commented May 21, 2022

andreisfr commented May 24, 2022

andreisfr commented Jul 3, 2022

gerekon commented Sep 24, 2022

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

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

Comments

aykevl commented Apr 14, 2022 • edited Loading

aykevl commented Apr 14, 2022 • edited Loading

aykevl commented Apr 14, 2022

aykevl commented Apr 15, 2022

aykevl commented Apr 20, 2022 • edited Loading

andreisfr commented May 19, 2022

aykevl commented May 21, 2022

andreisfr commented May 24, 2022

andreisfr commented Jul 3, 2022

gerekon commented Sep 24, 2022

aykevl commented Apr 14, 2022 •

edited

Loading

aykevl commented Apr 14, 2022 •

edited

Loading

aykevl commented Apr 20, 2022 •

edited

Loading