Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Oct 2023 06:37:19 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 274211] lang/tcc: Crashes with SIGSEGV on 14.x / 15.0-CURRENT when compiling hello world
Message-ID:  <bug-274211-7788-hbn28uLcnw@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-274211-7788@https.bugs.freebsd.org/bugzilla/>
References:  <bug-274211-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D274211

--- Comment #3 from Paul Floyd <pjfloyd@wanadoo.fr> ---
I just tried building the code.

So many warnings that it overflowed my terminal history. Most of them seem =
to
be related to some crappy macro that was probably written for 1970s compile=
rs
that didn't have "static". No surprise that junk like that crashes.


I fought with BSD make to get tcc to build something debuggable. In the end=
 I
just ran

make WITH_DEBUG=3D1

then cd'd to work/tinycc-release_0_9_26 and ran

gmake clean ; gmake CFLAGS=3D"-g -fno-omit-frame-pointer" LDFLAGS=3D"-g"

Valgrind still didn't want to read the debuginfo, don't know why.

The crash is here

     2532          if (sh->sh_type =3D=3D SHT_RELX) {=20
  >  2533              s->sh_info =3D sm_table[sh->sh_info].s->sh_num;

because sm_table[sh->sh_info].s is NULL.

It looks like sm_table is big enough - 26 elements allocated on line 2395 a=
nd
sh->sh_info is 3.

The file that tcc is reading is /usr/lib/crt1.o

readelf -a on that says

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000034  0000000000000000  AX       0     0     8
  [ 2] .rela.text        RELA             0000000000000000  00000108
       0000000000000030  0000000000000018   I      23     1     8
  [ 3] .eh_frame         X86_64_UNWIND    0000000000000000  00000078
       0000000000000038  0000000000000000   A       0     0     8
  [ 4] .rela.eh_frame    RELA             0000000000000000  00000138
       0000000000000018  0000000000000018   I      23     3     8

(and there are 26 section headers).

Something looks wrong there.


Assuming that sh->sh_info corresponds to the section header number above, b=
ut
the "if" in the code makes it look like SHT_RELX / RELA when in fact header=
 3
is
  [ 3] .eh_frame         X86_64_UNWIND

If I compare the readelf -a output on FreeBSD 13.2 it is quite different. F=
or a
start there is no .eh_frame at all.

So I reckon that tcc can't cope with the changed ELF contents of the object
file. That's likely to be down to the use of LLVM 16 in FreeBSD 14.

That's all for this morning.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-274211-7788-hbn28uLcnw>