Edmund Grimley Evans | 26 Feb 23:54 2015
Picon

arm64 relocations

The first part of the patch below changes arm64-gen.c to use the same
relocations that other compilers use on arm64, namely
R_AARCH64_ADR_PREL_PG_HI21 and R_AARCH64_ADD_ABS_LO12_NC.

The second part is an attempt to make tccelf.c cope with those
relocations.

Here's something TCC does better with the patch:

cat <<'EOF' > r.c
#include <stdio.h>
int main()
{
  printf("stdin : %p\n", &stdin);
  printf("stdout: %p\n", &stdout);
  return 0;
}
EOF

Before the patch:

$ ./tcc -B. -run r.c
stdin : 0x40a2d5d8
stdout: 0x435438

(It seems to be bypassing the GOT for stdin.)

After the patch:

$ ./tcc -B. -run r.c
(Continue reading)

Christian JULLIEN | 26 Feb 09:01 2015
Picon

RE :Re: New test 73_arm64 hangs if ran on RPi

Quickly reading your test, it looks like it is a pure C code that should? compile and run on any backend.
If it is the case, it should be named differently than arm64 to better understand what it tests.

This new test may exhibit a bug in arm32. Please note it also fails on x86_64, yet without core dump.

Test: 73_arm64...
--- 73_arm64.expect    2015-02-26 08:58:44.251349733 +0100
+++ 73_arm64.output    2015-02-26 08:59:12.168245410 +0100


Tcc developpers, does this test work/fail on other backend? like x86?

Christian


----- message d'origine -----
De : "Edmund Grimley Evans" <edmund.grimley.evans-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
date jeu. 26/02/2015 08:52 (GMT +01:00)
À : "tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : Re: [Tinycc-devel] New test 73_arm64 hangs if ran on RPi

Christian Jullien <eligis-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org>:

> I've a cron that tests every update on my RPi.
> Recent change introduced 73_arm64 that that hangs (at least) on RPi.
> As test name seems to suggest, it looks it is for arm64 (not arm32).
>
> Is this test really arm64 specific? If so, can you better check the tcc
> backend that should run this test?

It's arm64-specific in the sense that it tries things that I know are
difficult on arm64, such as passing particular kinds of struct as
argument and return value. However, it's supposed to be written in
correct C and should work on every architecture. It's possible that it
has exposed a bug in the arm back end as the calling convention for
32-bit ARM has some of the same complexities. I think I have a 32-bit
ARM chroot somewhere I can test it on so I'll see if I can narrow it
down a bit.

Edmund

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<p>Quickly reading your test, it looks like it is a pure C code that should? compile and run on any backend.<br>If it is the case, it should be named differently than arm64 to better understand what it tests.<br><br>This new test may exhibit a bug in arm32. Please note it also fails on x86_64, yet without core dump.<br><br>Test: 73_arm64...<br>--- 73_arm64.expect&nbsp;&nbsp;&nbsp; 2015-02-26 08:58:44.251349733 +0100<br>+++ 73_arm64.output&nbsp;&nbsp;&nbsp; 2015-02-26 08:59:12.168245410 +0100<br><br><br>Tcc developpers, does this test work/fail on other backend? like x86?<br><br>Christian<br><br><br></p>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"Edmund Grimley Evans"</span> <span dir="lrt">&lt;edmund.grimley.evans@...&gt;</span><br>date jeu. 26/02/2015 08:52 (GMT +01:00)<br>&Agrave; : <span dir="ltr">"tinycc-devel@..."</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : Re: [Tinycc-devel] New test 73_arm64 hangs if ran on RPi<br><br>Christian Jullien &lt;eligis@...&gt;:<br><br>&gt; I've a cron that tests every update on my RPi.<br>&gt; Recent change introduced 73_arm64 that that hangs (at least) on RPi.<br>&gt; As test name seems to suggest, it looks it is for arm64 (not arm32).<br>&gt; <br>&gt; Is this test really arm64 specific? If so, can you better check the tcc<br>&gt; backend that should run this test?<br><br>It's arm64-specific in the sense that it tries things that I know are<br>difficult on arm64, such as passing particular kinds of struct as<br>argument and return value. However, it's supposed to be written in<br>correct C and should work on every architecture. It's possible that it<br>has exposed a bug in the arm back end as the calling convention for<br>32-bit ARM has some of the same complexities. I think I have a 32-bit<br>ARM chroot somewhere I can test it on so I'll see if I can narrow it<br>down a bit.<br><br>Edmund<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
Christian Jullien | 26 Feb 06:41 2015
Picon

New test 73_arm64 hangs if ran on RPi

Hi All,

I've a cron that tests every update on my RPi.
Recent change introduced 73_arm64 that that hangs (at least) on RPi.
As test name seems to suggest, it looks it is for arm64 (not arm32).

Is this test really arm64 specific? If so, can you better check the tcc
backend that should run this test?

Test: 73_arm64...
Segmentation fault
--- 73_arm64.expect	2015-02-26 00:01:30.456048180 +0100
+++ 73_arm64.output	2015-02-26 00:04:04.754802954 +0100

Tia

Christian

Hernán J. González | 26 Feb 00:15 2015
Picon

An issue with literal floats

I don't understand how this happens. 

Notice that this is not an issue about floating point rounding, both
assignments (t2a t2b) should be exactly equivalent, but they are not.

/************************************************/
#include<stdio.h>
int main() {
    int t1 = 176401255;
    float f = 0.25f;
    int t2a = (int)(t1 * f);
    int t2b = (int)(t1 * (float)0.25f);
    printf("t2a=%d t2b=%d \n",t2a,t2b);
    return 0;
}
/************************************************/

prints 

t2a=44100313 t2b=44100312

Using tcc version 0.9.26 (i386 Win32)


--
Hernán J. González




--
Hernán J. González

<div><div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<div class="gmail_extra">I don't understand how this happens.&nbsp;</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">Notice that this is not an issue about floating point rounding, both</div>
<div class="gmail_extra">assignments (t2a t2b) should be exactly equivalent, but they are not.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">/************************************************/</div>
<div class="gmail_extra">
<div class="gmail_extra">#include&lt;stdio.h&gt;</div>
<div class="gmail_extra">int main() {<br>
</div>
<div class="gmail_extra">&nbsp; &nbsp; int t1 = 176401255;</div>
<div class="gmail_extra">&nbsp; &nbsp; float f = 0.25f;</div>
<div class="gmail_extra">&nbsp; &nbsp; int t2a = (int)(t1 * f);</div>
<div class="gmail_extra">&nbsp; &nbsp; int t2b = (int)(t1 * (float)0.25f);</div>
<div class="gmail_extra">&nbsp; &nbsp; printf("t2a=%d t2b=%d \n",t2a,t2b);</div>
<div class="gmail_extra">&nbsp; &nbsp; return 0;</div>
<div class="gmail_extra">}</div>
</div>
<div class="gmail_extra">/************************************************/<br>
</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">prints&nbsp;</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">t2a=44100313 t2b=44100312<br>
</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">Using tcc version 0.9.26 (i386 Win32)<span class="HOEnZb"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Hern&aacute;n J. Gonz&aacute;lez<div><br></div>
</div></div>
</span>
</div>
</div>
</div>
<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Hern&aacute;n J. Gonz&aacute;lez<div><br></div>
</div></div>
</div></div>
Christian Jullien | 24 Feb 06:39 2015
Picon

What license for arm64?

Hi all,

I'm very happy to see that TinyCC is going to have arm64 backend. Thank you
for that.

As you may know, TinyCC license is far from clear. Part of the code is under
GNU Lesser General Public License while other parts are close to BSD license
(see RELICENSING).

Daniel Glöckner, for example, asked to keep arm-gen.c  under LGPL.

For arm64, Edmund says:

* Copying and distribution of this file, with or without modification,
 * are permitted in any medium without royalty provided the copyright
 * notice and this notice are preserved.  This file is offered as-is,
 * without any warranty.

Which, with my non-lawyer eyes, looks similar to proposed text in
RELICENSING.

As much as possible, could TinyCC use either LGPL or text in RELICENSING

M2c.

Christian

Edmund Grimley Evans | 21 Feb 00:55 2015
Picon

[PATCH] When handling '.' operator, cope with VT_LLOCAL

Does this look all right?

Commit message:

    tccgen.c: When handling '.' operator, cope with VT_LLOCAL.

    If vtop->r before gaddrof() was (VT_LLOCAL | VT_LVAL) and the field
    offset was zero, so gen_op('+') was optimised away, then vtop->r
    can be (VT_LOCAL | VT_LVAL) after the '+', in which case we must
    reinstate the VT_LLOCAL instead of just setting VT_LVAL.
Does this look all right?

Commit message:

    tccgen.c: When handling '.' operator, cope with VT_LLOCAL.

    If vtop->r before gaddrof() was (VT_LLOCAL | VT_LVAL) and the field
    offset was zero, so gen_op('+') was optimised away, then vtop->r
    can be (VT_LOCAL | VT_LVAL) after the '+', in which case we must
    reinstate the VT_LLOCAL instead of just setting VT_LVAL.
Edmund Grimley Evans | 21 Feb 00:50 2015
Picon

[PATCH] deprecating VT_REF

VT_REF is not mentioned in the documentation and seems to be used only
for x86_64. Also, it seems to be the same thing as VT_LLOCAL, really.
This could be a first step towards removing it altogether.

Commit message:

    Make it explicit that VT_REF is used only for TCC_TARGET_X86_64.

    tcc.h: Make the definition conditional on TCC_TARGET_X86_64.
    tccgen.c: Since the VT_REF bit is set only in x86_64-gen.c we
              can make clearing it and testing for it conditional.
Attachment (2015-02-20-VT_REF.patch): text/x-diff, 2107 bytes
VT_REF is not mentioned in the documentation and seems to be used only
for x86_64. Also, it seems to be the same thing as VT_LLOCAL, really.
This could be a first step towards removing it altogether.

Commit message:

    Make it explicit that VT_REF is used only for TCC_TARGET_X86_64.

    tcc.h: Make the definition conditional on TCC_TARGET_X86_64.
    tccgen.c: Since the VT_REF bit is set only in x86_64-gen.c we
              can make clearing it and testing for it conditional.
Edmund Grimley Evans | 20 Feb 15:15 2015
Picon

Re: Fallout from commit 01c041923474750a236da02561f0f8835

Michael Matz on 2014-09-18:

>   extern void f(void);
>   g() { void (*ptr)(void) = f; ptr(); }
>
> Here there will be a GOT slot allocated for 'f'.  The initialization of 
> 'ptr' will load from that GOT slot.  So even though direct calls to 'f' 
> can (and will be, when 'f' is defined) fully resolved without a PLT slot, 

If f is in a library it may turn out not to be in range for a direct
call. So in general you need the PLT (or the old jump table).

> Probably I'd have to use that exact debian-based setup under qemu (my 
> chroot is based on some openSUSE version), but I don't know a simple 
> recipe for how.  Any help appreciated.

You could try taking debootstrap from the Debian archive, unpacking it
manually, and running it as root thus:

.../debootstrap --arch armhf unstable .../chroots/arm64-unstable http://ftp.debian.org/debian

I've done that before for creating a Debian chroot on a non-Debian
Linux machine. It's also what I use for creating a chroot for a
different architecture, such as arm64 on i386 (with QEMU), or armhf on
arm64 (without QEMU).

Edmund

Naper Hamza | 19 Feb 21:22 2015
Picon

Some tcc questions

Hello , I wanna know if tcc have a global config , where we can change some stuff , if not why not implementing one ? 


Also I wanna know if a official tcc organization is available on GitHub  , which means also if a official tcc repo is available too . 

Wanna contribute to tcc , waiting for you reply 

Thank you 
<div>
<p>Hello , I wanna know if tcc have a global&nbsp;config , where we can change some stuff , if not why not implementing one ?&nbsp;</p>
<div><br></div>
<div>Also I wanna know if a official tcc organization is available on GitHub&nbsp;<span></span>&nbsp;, which means also if a official tcc repo is available too .&nbsp;</div>
<div><br></div>
<div>Wanna contribute to tcc , waiting for you reply&nbsp;</div>
<div><br></div>
<div>Thank you&nbsp;</div>
</div>
Edmund Grimley Evans | 19 Feb 16:37 2015
Picon

[PATCH] TCC arm64 back end

It's not finished, but a lot of things seem to work, and there's a
problem with the linker that perhaps someone could help me with.

See README.arm64 for details.

Thanks,

Edmund
Attachment (2015-02-19-arm64.patch.gz): application/octet-stream, 47 KiB
It's not finished, but a lot of things seem to work, and there's a
problem with the linker that perhaps someone could help me with.

See README.arm64 for details.

Thanks,

Edmund
Edmund Grimley Evans | 17 Feb 10:00 2015
Picon

[PATCH] use RELA relocations properly for R_DATA_PTR

Try this on x86_64:

cat <<END > t1.c
extern int x[];
int *p = &x[4];
END

cat <<END > t2.c
#include <stdio.h>
int x[10];
extern int *p;
int main()
{
  printf("%lld\n", (long long)(p - x));
  return 0;
}
END

At first sight this appears to work as expected with both GCC and TCC
as compiler or linker:

gcc -Wall -O2 -c t1.c -o t1.gcc.o
gcc -Wall -O2 -c t2.c -o t2.gcc.o

./tcc -B. -c t1.c -o t1.tcc.o
./tcc -B. -c t2.c -o t2.tcc.o

gcc t[12].gcc.o -o t.gg.exe
./tcc -B. libtcc1.a t[12].gcc.o -o t.gt.exe
gcc t[12].tcc.o -o t.tg.exe
./tcc -B. libtcc1.a t[12].tcc.o -o t.tt.exe

All four executables print "4".

However, when you look at the relocations in t1.?cc.o you find
something strange:

readelf -r t1.gcc.o
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000800000001 R_X86_64_64       0000000000000000 x + 10

readelf -r t1.tcc.o
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000300000001 R_X86_64_64       0000000000000000 x + 0

With TCC the addend is zero! Apparently TCC is putting the offset is
in the data section:

readelf -x .data t1.gcc.o
  0x00000000 00000000 00000000                   ........

readelf -x .data t1.tcc.o
  0x00000000 10000000 00000000                   ........

Now this isn't how RELA relocations are normally described as working,
though I'm not sure that it's wrong. I haven't found a document that
says you have to ignore what value is "in the place" with a RELA
relocation, and looking at the source for lld (LLVM's linker) it
appears that that linker ORs the symbol value plus addend with the
value in the place in the case of R_X86_64_64 ...

Anyway, the attached patch makes TCC generate proper RELA relocations
like GCC does, putting zero in the place so it doesn't matter whether
the linker then ignores that value, adds it, or ORs it.

Proposed commit message:

Use RELA relocations properly for R_DATA_PTR on x86_64.

libtcc.c: Add greloca, a generalisation of greloc that takes an addend.
tcc.h: Add greloca and put_elf_reloca.
tccelf.c: Add put_elf_reloca, a generalisation of put_elf_reloc.
tccgen.c: On x86_64, use greloca instead of greloc in init_putv.
Try this on x86_64:

cat <<END > t1.c
extern int x[];
int *p = &x[4];
END

cat <<END > t2.c
#include <stdio.h>
int x[10];
extern int *p;
int main()
{
  printf("%lld\n", (long long)(p - x));
  return 0;
}
END

At first sight this appears to work as expected with both GCC and TCC
as compiler or linker:

gcc -Wall -O2 -c t1.c -o t1.gcc.o
gcc -Wall -O2 -c t2.c -o t2.gcc.o

./tcc -B. -c t1.c -o t1.tcc.o
./tcc -B. -c t2.c -o t2.tcc.o

gcc t[12].gcc.o -o t.gg.exe
./tcc -B. libtcc1.a t[12].gcc.o -o t.gt.exe
gcc t[12].tcc.o -o t.tg.exe
./tcc -B. libtcc1.a t[12].tcc.o -o t.tt.exe

All four executables print "4".

However, when you look at the relocations in t1.?cc.o you find
something strange:

readelf -r t1.gcc.o
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000800000001 R_X86_64_64       0000000000000000 x + 10

readelf -r t1.tcc.o
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000300000001 R_X86_64_64       0000000000000000 x + 0

With TCC the addend is zero! Apparently TCC is putting the offset is
in the data section:

readelf -x .data t1.gcc.o
  0x00000000 00000000 00000000                   ........

readelf -x .data t1.tcc.o
  0x00000000 10000000 00000000                   ........

Now this isn't how RELA relocations are normally described as working,
though I'm not sure that it's wrong. I haven't found a document that
says you have to ignore what value is "in the place" with a RELA
relocation, and looking at the source for lld (LLVM's linker) it
appears that that linker ORs the symbol value plus addend with the
value in the place in the case of R_X86_64_64 ...

Anyway, the attached patch makes TCC generate proper RELA relocations
like GCC does, putting zero in the place so it doesn't matter whether
the linker then ignores that value, adds it, or ORs it.

Proposed commit message:

Use RELA relocations properly for R_DATA_PTR on x86_64.

libtcc.c: Add greloca, a generalisation of greloc that takes an addend.
tcc.h: Add greloca and put_elf_reloca.
tccelf.c: Add put_elf_reloca, a generalisation of put_elf_reloc.
tccgen.c: On x86_64, use greloca instead of greloc in init_putv.

Gmane