Another input that may help.
Investigating further, I've found a possible cause of empty address here
(else clause):
/* second short pass to update sh_link and sh_info fields of new
sections */
for(i = 1; i < ehdr.e_shnum; i++) {
s = sm_table[i].s;
if (!s || !sm_table[i].new_section)
continue;
sh = &shdr[i];
if (sh->sh_link > 0)
s->link = sm_table[sh->sh_link].s;
if (sh->sh_type == SHT_RELX) {
if (sm_table[sh->sh_info].s) {
s->sh_info =
sm_table[sh->sh_info].s->sh_num;
/* update backward link */
s1->sections[s->sh_info]->reloc = s;
} else {
/* we haven't read the target of relocs, so
cancel them */
s->data_offset = sm_table[i].oldlen;
sm_table[i].s = NULL;
}
}
}
Trying with
} else {
/* we haven't read the target of relocs, so
cancel them */
s->sh_type = SHT_NULL;
s->data_offset = sm_table[i].oldlen;
sm_table[i].s = NULL;
}
}
Is another way to solve the issue. For example, this else section is never
called on Debian ARM (RPi) and called on the section that hangs on Fedora
29. Not sure if SHT_NULL is the right value to set in this case.
C.
From: Christian Jullien [mailto:[email protected]]
Sent: jeudi 7 mars 2019 08:23
To: '[email protected]'
Subject: RE: [Tinycc-devel] TCC segfault on Fedora 29 (more info toward a
fix)
Michael, I had time to investigate further.
I first added this trace around core dump:
/* Allocate strings for section names and decide if an unallocated section
should be output.
NOTE: the strsec section comes last, so its size is also correct ! */
static int alloc_sec_names(TCCState *s1, int file_type, Section *strsec)
{
int i;
Section *s;
int textrel = 0;
/* Allocate strings for section names */
for(i = 1; i < s1->nb_sections; i++) {
s = s1->sections[i];
/* when generating a DLL, we include relocations but we may
patch them */
printf("i = %d, s->sh_type = %d (%d), s->sh_info = %d,
s1->sections[s->sh_info] = %p\n",
i, s->sh_type, SHT_RELX, s->sh_info,
s1->sections[s->sh_info]);
I then got
i = 1, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 2, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 3, s->sh_type = 8 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 4, s->sh_type = 2 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 5, s->sh_type = 3 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 6, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 7, s->sh_type = 4 (4), s->sh_info = 6, s1->sections[s->sh_info] =
0x142a360
i = 8, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 9, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 10, s->sh_type = 4 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
Segmentation fault (core dumped)
Adding one more test in if condition
/* Allocate strings for section names */
for(i = 1; i < s1->nb_sections; i++) {
s = s1->sections[i];
/* when generating a DLL, we include relocations but we may
patch them */
printf("i = %d, s->sh_type = %d (%d), s->sh_info = %d,
s1->sections[s->sh_info] = %p\n",
i, s->sh_type, SHT_RELX, s->sh_info,
s1->sections[s->sh_info]);
if (file_type == TCC_OUTPUT_DLL &&
s->sh_type == SHT_RELX &&
!(s->sh_flags & SHF_ALLOC) &&
s1->sections[s->sh_info] &&
(s1->sections[s->sh_info]->sh_flags & SHF_ALLOC) &&
prepare_dynamic_rel(s1, s)) {
if (s1->sections[s->sh_info]->sh_flags & SHF_EXECINSTR)
textrel = 1;
I have been able to run full tinycc tests wo error / core dump. More
specifically, trace becomes:
i = 1, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 2, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 3, s->sh_type = 8 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 4, s->sh_type = 2 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 5, s->sh_type = 3 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 6, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 7, s->sh_type = 4 (4), s->sh_info = 6, s1->sections[s->sh_info] =
0x2346360
i = 8, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 9, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 10, s->sh_type = 4 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 11, s->sh_type = 4 (4), s->sh_info = 1, s1->sections[s->sh_info] =
0x233e860
i = 12, s->sh_type = 4 (4), s->sh_info = 2, s1->sections[s->sh_info] =
0x233e8f0
i = 13, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 14, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 15, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 16, s->sh_type = 11 (4), s->sh_info = 0, s1->sections[s->sh_info] =
(nil)
i = 17, s->sh_type = 3 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 18, s->sh_type = 5 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 19, s->sh_type = 6 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 20, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 21, s->sh_type = 4 (4), s->sh_info = 20, s1->sections[s->sh_info] =
0x2346c10
i = 22, s->sh_type = 1 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
i = 23, s->sh_type = 3 (4), s->sh_info = 0, s1->sections[s->sh_info] = (nil)
Now I've no idea what happens when s->sh_type == SHT_RELX and
s1->sections[s->sh_info] == NULL nor this patch is the correct fix.
I count on you now :o))
C.
-----Original Message-----
From: Christian Jullien [mailto:[email protected]]
Sent: mardi 5 mars 2019 16:04
To: '[email protected]'
Subject: RE: [Tinycc-devel] TCC segfault on Fedora 29
Hello Michael,
I recompiled tcc with -O0 here is was I get. Don't hesitate to ask me
more...
[jullien@fedora64 tests]$ gdb --args ../tcc -B.. -I../include -I.. -I..
-DCONFIG_LDDIR="\"lib64\"" -DTCC_TARGET_X86_64 -DHAVE_SELINUX
-DLIBTCC_AS_DLL ../libtcc.c -lm -ldl -shared -o libtcc2.so
..
(gdb) run
Starting program: /home/jullien/tinycc/tcc -B.. -I../include -I.. -I..
-DCONFIG_LDDIR=\"lib64\" -DTCC_TARGET_X86_64 -DHAVE_SELINUX -DLIBTCC_AS_DLL
../libtcc.c -lm -ldl -shared -o libtcc2.so
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.28-26.fc29.x86_64
Program received signal SIGSEGV, Segmentation fault.
alloc_sec_names (s1=0x469260, file_type=3, strsec=0x568610) at tccelf.c:1541
1541 (s1->sections[s->sh_info]->sh_flags & SHF_ALLOC) &&
(gdb) bt
#0 alloc_sec_names (s1=0x469260, file_type=3, strsec=0x568610) at
tccelf.c:1541
#1 0x0000000000423842 in elf_output_file (s1=0x469260, filename=0x46e590
"libtcc2.so") at tccelf.c:2132
#2 0x0000000000423cf4 in tcc_output_file (s=0x469260, filename=0x46e590
"libtcc2.so") at tccelf.c:2245
#3 0x0000000000403be0 in main (argc0=15, argv0=0x7fffffffd668) at tcc.c:358
(gdb) info locals
i = 10
s = 0x4716d0
textrel = 0
(gdb) print *s
$1 = {data_offset = 144, data = 0x471780 "\024", data_allocated = 256,
sh_name = 0, sh_num = 10, sh_type = 4, sh_flags = 64, sh_info = 0,
sh_addralign = 8, sh_entsize = 24, sh_size = 0, sh_addr = 0,
sh_offset = 0, nb_hashed_syms = 0, link = 0x469ad0, reloc = 0x0, hash =
0x0, prev = 0x0, name = "."}
(gdb) print *s1
$2 = {verbose = 0, nostdinc = 0, nostdlib = 0, nocommon = 1, static_link =
0, rdynamic = 0, symbolic = 0, filetype = 0, cversion = 199901, tcc_lib_path
= 0x469820 "..", soname = 0x0, rpath = 0x0,
enable_new_dtags = 0, output_type = 3, output_format = 0, char_is_unsigned
= 0, leading_underscore = 0, ms_extensions = 1, dollars_in_identifiers = 0,
ms_bitfields = 0, warn_write_strings = 0,
warn_unsupported = 0, warn_error = 0, warn_none = 0,
warn_implicit_function_declaration = 1, warn_gcc_compat = 0, do_debug = 0,
do_bounds_check = 0, run_test = 0, text_addr = 0, has_text_addr = 0,
section_align = 0, init_symbol = 0x0, fini_symbol = 0x0, nosse = 0,
loaded_dlls = 0x5685b0, nb_loaded_dlls = 4, include_paths = 0x46e560,
nb_include_paths = 3, sysinclude_paths = 0x46e6a0,
nb_sysinclude_paths = 3, library_paths = 0x46e730, nb_library_paths = 3,
crt_paths = 0x46e760, nb_crt_paths = 1, cmd_include_files = 0x0,
nb_cmd_include_files = 0, error_opaque = 0x0,
error_func = 0x0, error_set_jmp_enabled = 0, error_jmp_buf = {{__jmpbuf =
{0, 2321536552689024907, 4203648, 140737488344672, 0, 0,
2321536552693219211, -2321537099244945525}, __mask_was_saved = 0,
__saved_mask = {__val = {0 <repeats 16 times>}}}}, nb_errors = 0, ppfp
= 0x7ffff7e1f780 <_IO_2_1_stdout_>, Pflag = LINE_MACRO_OUTPUT_FORMAT_GCC,
dflag = 0 '\000', target_deps = 0x46b650,
nb_target_deps = 200, include_stack = {0x46e780, 0x471d10, 0x592ff0,
0x592ff0, 0x57f890, 0x518250, 0x4abaa0, 0x0 <repeats 25 times>},
include_stack_ptr = 0x469478, ifdef_stack = {0, 1, 1, 0, 1, 2, 1,
1, 2, 1, 0 <repeats 54 times>}, ifdef_stack_ptr = 0x469580,
cached_includes_hash = {57, 38, 83, 22, 0, 48, 43, 60, 78, 86, 75, 53, 84,
76, 58, 74, 79, 0, 88, 34, 71, 54, 65, 18, 82, 81, 87, 85, 0,
13, 69, 59}, cached_includes = 0x517e40, nb_cached_includes = 88,
pack_stack = {0, 0, 0, 0, 0, 0, 0, 0}, pack_stack_ptr = 0x469714,
pragma_libs = 0x0, nb_pragma_libs = 0, inline_fns = 0x0,
nb_inline_fns = 0, sections = 0x4a93f0, nb_sections = 24, priv_sections =
0x469f50, nb_priv_sections = 5, got = 0x471c40, plt = 0x595080,
dynsymtab_section = 0x469d10, dynsym = 0x581430,
symtab = 0x469ad0, sym_attrs = 0x5ca040, nb_sym_attrs = 2048, runtime_main
= 0x0, runtime_mem = 0x0, nb_runtime_mem = 0, files = 0x46e5f0, nb_files =
3, nb_libraries = 2,
outfile = 0x46e590 "libtcc2.so", option_r = 0, do_bench = 0, gen_deps = 0,
deps_outfile = 0x0, option_pthread = 0, argc = 0, argv = 0x0}
C.
-----Original Message-----
From: Tinycc-devel [mailto:[email protected]]
On Behalf Of Michael Matz
Sent: lundi 4 mars 2019 18:48
To: [email protected]
Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29
Hi,
On Mon, 4 Mar 2019, Christian Jullien wrote:
> Ooops, not quite.
> I missed this line on log file (from Fedora 29).
> Btw, as suggested by ./configure, Fedora 29 requires --with-selinux
>
> ------------ dlltest ------------
> ../tcc -B.. -I../include -I.. -I.. -DCONFIG_LDDIR="\"lib64\""
> -DTCC_TARGET_X86_64 -DHAVE_SELINUX -DLIBTCC_AS_DLL ../libtcc.c -lm -ldl
> -shared -o libtcc2.so
> make[1]: *** [Makefile:132: dlltest] Segmentation fault (core dumped)
Different bug? I don't have fedora 29 so can't debug this myself, what
does the gdb backtrace look like for the coredump (to make that easier,
build tcc with '-O0 -g', not the default -O2, i.e. change CFLAGS in
config.mak).
Ciao,
Michael.
>
> -----Original Message-----
> From: Tinycc-devel
[mailto:[email protected]]
> On Behalf Of Michael Matz
> Sent: lundi 4 mars 2019 16:58
> To: [email protected]
> Subject: Re: [Tinycc-devel] TCC segfault on Fedora 29
>
> Hi,
>
> On Fri, 1 Mar 2019, Klaus Ebbe Grue wrote:
>
> > Is there news on the Fedora 29 segfault problem?
>
> No, as nobody provided the breaking crt*.o files ...
>
> > > some time. Alternatively: somebody can send me their /usr/lib64/crt*.o
> > > files from a system where the segfault reproduces. It's some unhandled
> >
> > I have included my /usr/lib64/crt*.o files, if that helps (I hope the
> > mailing list accepts attachments).
>
> ... until now. Fixed in mob.
>
>
> Ciao,
> Michael.
>
> _______________________________________________
> 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
>
_______________________________________________
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
