On 25.01.2026 00:24, Stefanos via Tinycc-devel wrote:
It seems the issue comes from the latest release of binutils and libc6-*
updates that took place in GNU / Linux Debian testing 64-bit.
Obviously this is a hypothesis, but...it took place after I upgraded from one
version to another (the latest).
Package version(s):
binutils 2.45.50.20251209-1+b1
libc6-* 2.42-10+b1
What I find quite interesting is the following behavior which I'm about to
describe below.
Yes, interesting ...
Did you check that "/usr/lib/x86_64-linux-gnu/crt1.o" too?
Because from your report it seems that it has two sections
with same name ".note.GNU-stack" but different types (SHT_NOTE/SHT_PROGBITS).
Which indeed seems interesting, maybe even illegal ...
-- gr
This tiny code
#include <stdio.h>
int main(void)
{
puts("Hello world!");
return 0;
}
if used with `gcc -c tmp.c -o gcctmp.o`, when inspected with `readelf -S
gcctmp.o`, you get the following output:
There are 13 section headers, starting at offset 0x218:
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
000000000000001a 0000000000000000 AX 0 0 1
[ 2] .rela.text RELA 0000000000000000 00000168
0000000000000030 0000000000000018 I 10 1 8
[ 3] .data PROGBITS 0000000000000000 0000005a
0000000000000000 0000000000000000 WA 0 0 1
[ 4] .bss NOBITS 0000000000000000 0000005a
0000000000000000 0000000000000000 WA 0 0 1
[ 5] .rodata PROGBITS 0000000000000000 0000005a
000000000000000d 0000000000000000 A 0 0 1
[ 6] .comment PROGBITS 0000000000000000 00000067
0000000000000020 0000000000000001 MS 0 0 1
[ 7] .note.GNU-stack PROGBITS 0000000000000000 00000087
0000000000000000 0000000000000000 0 0 1
[ 8] .eh_frame PROGBITS 0000000000000000 00000088
0000000000000038 0000000000000000 A 0 0 8
[ 9] .rela.eh_frame RELA 0000000000000000 00000198
0000000000000018 0000000000000018 I 10 8 8
[10] .symtab SYMTAB 0000000000000000 000000c0
0000000000000090 0000000000000018 11 4 8
[11] .strtab STRTAB 0000000000000000 00000150
0000000000000011 0000000000000000 0 0 1
[12] .shstrtab STRTAB 0000000000000000 000001b0
0000000000000061 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
if used with `tcc -c tmp.c -o tcctmp.o`, when inspected with `readelf -S
tcctmp.o`, you get the following output:
There are 11 section headers, starting at offset 0x40:
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 00000300
0000000000000021 0000000000000000 AX 0 0 8
[ 2] .data PROGBITS 0000000000000000 00000330
0000000000000000 0000000000000000 WA 0 0 8
[ 3] .data.ro PROGBITS 0000000000000000 00000330
000000000000000d 0000000000000000 A 0 0 8
[ 4] .bss NOBITS 0000000000000000 00000340
0000000000000000 0000000000000000 WA 0 0 8
[ 5] .symtab SYMTAB 0000000000000000 00000340
0000000000000090 0000000000000018 6 4 8
[ 6] .strtab STRTAB 0000000000000000 000003d0
0000000000000019 0000000000000000 0 0 1
[ 7] .eh_frame PROGBITS 0000000000000000 000003f0
0000000000000040 0000000000000000 A 0 0 8
[ 8] .rela.text RELA 0000000000000000 00000430
0000000000000030 0000000000000018 5 1 8
[ 9] .rela.eh_frame RELA 0000000000000000 00000460
0000000000000018 0000000000000018 5 7 8
[10] .shstrtab STRTAB 0000000000000000 00000480
0000000000000059 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
One thing that caught my eye was section `[3] .data.ro`...why specifically this
format and not `.rodata`...? Why the difference?
Another observation is why section `[8] .rela.text` is not below section `[1]
.text` as section [2]?
Now, the interesting part takes place when I try to output an executable for
TCC with the following command:
$ tcc tcctmp.o -o tccoutput
/usr/lib/x86_64-linux-gnu/crt1.o: error: section type conflict: .note.GNU-stack
01 <> 07 Segmentation fault (core dumped) tcc tcctmp.o -o tccoutput
As you can see, it segfaults, and if I run it with `coredumpctl debug`, I get
the following output:
PID: 126688 (tcc)
UID: 1000 (stefanos)
GID: 1000 (stefanos)
Signal: 11 (SEGV)
Timestamp: Sun 2026-01-25 01:10:32 EET (1min 44s ago)
Command Line: tcc tcctmp.o -o tccoutput
Executable: /usr/local/bin/tcc
Control Group: /user.slice/user-1000.slice/session-1.scope
Unit: session-1.scope
Slice: user-1000.slice
Session: 1
Owner UID: 1000 (stefanos)
Boot ID: 623de3b52551467dacd95654d607f678
Machine ID: 8c7db6fc6680a4087c9dca0452dbd717
Hostname: debian
Storage:
/var/lib/systemd/coredump/core.tcc.1000.623de3b52551467dacd95654d607f678.126688.1769296232000000.zst
(present) Size on Disk: 100.5K Message: Process 126688 (tcc) of user
1000 dumped core.
Stack trace of thread 126688:
#0 0x0000556866a19dcf relocate_sections (/usr/local/bin/tcc +
0x2ddcf) #1 0x0000556866a1c99e tcc_output_file (/usr/local/bin/tcc
+ 0x3099e) #2 0x00005568669efb3c main (/usr/local/bin/tcc + 0x3b3c)
#3 0x00007f0afbd43f75 __libc_start_call_main (libc.so.6 +
0x29f75) #4 0x00007f0afbd44027 __libc_start_main_impl (libc.so.6 +
0x2a027) #5 0x00005568669eff61 _start (/usr/local/bin/tcc + 0x3f61)
ELF object binary architecture: AMD x86-64
GNU gdb (Debian 17.1-1) 17.1
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/tcc...
(No debugging symbols found in /usr/local/bin/tcc)
[New LWP 126688]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/bin/tcc tcctmp.o -o tccoutput'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000556866a19dcf in relocate_sections ()
(gdb) bt
#0 0x0000556866a19dcf in relocate_sections ()
#1 0x0000556866a1c99e in tcc_output_file ()
#2 0x00005568669efb3c in main ()
The funny part is when I run `gcc tcctmp.o -o gccTCCoutput` and works just fine
and when I run it, it prints "Hello world!", as it should.
If I try the opposite now `tcc gcctmp.o -o tccGCCoutput`, it stops immediately
with
/usr/lib/x86_64-linux-gnu/crt1.o: error: section type conflict: .note.GNU-stack
01 <> 07 gcctmp.o: error: section type conflict: .note.GNU-stack 01 <> 07
So clearly something is wrong with linkage process...I have asked another
person from IRC (Debian channel) to fetch the repo and try to compile it and run
the `make test` command and reported the same error as I have originally
reported, which means I'm not the only one who goes through this.
Can someone confirm this or if my toolchain is corrupted how to fix it?
I have tried to force-install it again with negative results.
Can anyone advice me how to remedy this issue as I cannot use TCC anymore?
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
