Re: [Tinycc-devel] segfault when using tcc -run on Fedora 21 and 22

[Vincent Lefevre]

On 2016-01-09 15:02:11 -0500, Dylan Cali wrote:
> tcc -run is segfaulting for me, and after inspecting the core dump the
> cause is not obvious to me.  I'm not sure if this is a tinycc bug or
> something specific to my system.  I'm inclined to think it's something
> with tinycc, as I'm experiencing the issue on both Fedora 21 and
> Fedora 22.
> 
> Here is the relevant output from make test off a fresh clone and build:
> 
> dcali-fedora (mob[release_0_9_26-611]=) ~/git/tinycc
> $ make test
> make: Warning: File 'config.mak' has modification time 0.031 s in the future
> make -C tests test 'PROGS_CROSS=i386-tcc i386-win-tcc x86_64-win-tcc
> arm-linux-fpa-tcc arm-linux-fpa-ld-tcc arm-linux-gnu-tcc
> arm-linux-gnueabi-tcc arm64-tcc c67-tcc arm-win-mingw32ce-tcc'
> make[1]: Entering directory '/home/dylan.cali/git/tinycc/tests'
> make[1]: Warning: File '../config.mak' has modification time 0.029 s
> in the future
> ------------ hello-exe ------------
> ../tcc -B.. -I.. -I.. -I../include -L.. ../examples/ex1.c -o hello ||
> (../tcc -vv; exit 1) && ./hello
> Hello World
> ------------ hello-run ------------
> ../tcc -B.. -I.. -I.. -I../include -L.. -run ../examples/ex1.c
> Makefile:94: recipe for target 'hello-run' failed
> make[1]: *** [hello-run] Segmentation fault
> make[1]: Leaving directory '/home/dylan.cali/git/tinycc/tests'
> Makefile:377: recipe for target 'test' failed
> make: *** [test] Error 2

This problem was due to new psABI relocation but should have been
fixed for x86_64 on 2015-12-17. At least the latest mob branch works
on my machines. Just in case, make sure that the following appears
in "git log":

commit f15c0a93336ef42cec51d00667b5fd60fb309cd5
Author: Michael Matz <address@hidden>
Date:   2015-12-17 19:41:20 +0100

    x86-64: fix shared libs
    
    The introduction of read32le everywhere created a subtle issue, going
    from
       x = *(int*)p;
    to
       x = read32le(p);
    is not equivalent if x is a larger than 32bit quantity, like an
    address on x86_64, because read32le returns an unsigned int.  The first
    sign extends, the latter zero extends.  This broke shared library
    creation for gawk.  It's enough to amend the case of the above
    situation, cases like "write32le(p, read32le(p) +- something)" are okay,
    no extensions happen or matter.

commit e264243adc0910fba204fd05292a8353e272bd0e
Author: Michael Matz <address@hidden>
Date:   2015-12-17 07:30:35 +0100

    x86-64: Define symbol constant for new relocs
    
    Whoops, we have our own <elf.h> copy, so I can just as well add
    the symbol defines for the relocs instead of hard-coding numbers
    in tccelf.c.

commit c4d0498b3ae3483fa7726500bd03e1f411289fff
Author: Michael Matz <address@hidden>
Date:   2015-12-17 07:17:34 +0100

    x86-64: Add support for new psABI relocations
    
    R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX can occur in object files
    comiled by new binutils.  They are not dynamic relocations, so normally
    wouldn't be a problem for tcc (one doesn't normally mix object files
    created by different compiler/binutils, static archives are so out :)).
    If it weren't for the glibc startup code, crt*.o, of course.  They now
    do contain such relocs --> boom.  Handle them in the trivial way.

-- 
Vincent Lefèvre <address@hidden> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)