TinyCC failure on i386

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

TinyCC failure on i386

Giovanni Mascellani
Hi,

TinyCC fails to test on i386 on the CI that I just set up. Apparently,
though, the problem is not in tcc, but in gcc, which is used to compile
the test program too and compare the results.

I managed to trim down the offending example to this:

int main() {
    asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
    return 0;
}

If I compile this with gcc (9.2) on Debian this happens:

$ gcc -g -m32 test.c
test.c: In function ‘main’:
test.c:3:5: warning: asm operand 0 probably doesn’t match constraints
    3 |     asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
      |     ^~~
test.c:3:5: error: impossible constraint in ‘asm’

I believe this is wrong, "i" should accept a literal string as value.
Also, the same program works on Compiler Explorer[1].

 [1] https://godbolt.org/z/xAP-dy

I suspect this might be a bug in Debian's gcc. Anybody not using Debian
could please try to compile this program and see what happens?

Thanks, Giovanni.
--
Giovanni Mascellani <[hidden email]>
Postdoc researcher - Université Libre de Bruxelles


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TinyCC failure on i386

Czcibor Bohusz-Dobosz

The same seems to happen on Arch Linux:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

$ gcc -m32 offending.c
offending.c: In function ‘main’:
offending.c:2:5: warning: asm operand 0 probably doesn’t match constraints
    2 |     asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
      |     ^~~
offending.c:2:5: error: impossible constraint in ‘asm’

- Czcibor

W dniu 13.12.2019 o 15:19, Giovanni Mascellani pisze:
Hi,

TinyCC fails to test on i386 on the CI that I just set up. Apparently,
though, the problem is not in tcc, but in gcc, which is used to compile
the test program too and compare the results.

I managed to trim down the offending example to this:

int main() {
    asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
    return 0;
}

If I compile this with gcc (9.2) on Debian this happens:

$ gcc -g -m32 test.c
test.c: In function ‘main’:
test.c:3:5: warning: asm operand 0 probably doesn’t match constraints
    3 |     asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
      |     ^~~
test.c:3:5: error: impossible constraint in ‘asm’

I believe this is wrong, "i" should accept a literal string as value.
Also, the same program works on Compiler Explorer[1].

 [1] https://godbolt.org/z/xAP-dy

I suspect this might be a bug in Debian's gcc. Anybody not using Debian
could please try to compile this program and see what happens?

Thanks, Giovanni.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: TinyCC failure on i386

Michael Matz-4
In reply to this post by Giovanni Mascellani
Hello,

On Fri, 13 Dec 2019, Giovanni Mascellani wrote:

> TinyCC fails to test on i386 on the CI that I just set up. Apparently,
> though, the problem is not in tcc, but in gcc, which is used to compile
> the test program too and compare the results.
>
> I managed to trim down the offending example to this:
>
> int main() {
>     asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
>     return 0;
> }
>
> If I compile this with gcc (9.2) on Debian this happens:
>
> $ gcc -g -m32 test.c
> test.c: In function ‘main’:
> test.c:3:5: warning: asm operand 0 probably doesn’t match constraints
>     3 |     asm volatile ("mov %%eax, %%eax\n" : : "i" ("A string"));
>       |     ^~~
> test.c:3:5: error: impossible constraint in ‘asm’
>
> I believe this is wrong, "i" should accept a literal string as value.
> Also, the same program works on Compiler Explorer[1].
>
>  [1] https://godbolt.org/z/xAP-dy
>
> I suspect this might be a bug in Debian's gcc. Anybody not using Debian
> could please try to compile this program and see what happens?
I had now time to look into this.  The immediate cause is that new Debian
enables PIC by default also with -m32, which triggers the error message.  
It was always there, i.e. the construct used in the kernel is only usable
with either x86-64 or without -fPIC/-fPIE on i386.  There are ways to
write this construct without triggering the error message, but I want to
test the thing as written in the kernel.  So the only option besides
disabling the test is to force non-PIC code for it on i386, which
means for the whole file.  I've done that now on mob with a lengthy
comment in tcctest.c.

Oh, and the testing pipeline is useful, thanks for setting it up :-)  
(Though it would be nice if at least the native machines, i.e.
i386 and x86-64, wouldn't use a full system emulation seemingly without
paravirt; 8 minutes for a testrun of tcc seems a bit excessive; but as you
said, definitely better than nothing :) )


Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

CI improvements (was: Re: TinyCC failure on i386)

Giovanni Mascellani
Hi,

Il 17/12/19 18:11, Michael Matz ha scritto:
> I had now time to look into this.  The immediate cause is that new Debian
> enables PIC by default also with -m32, which triggers the error message.  
> It was always there, i.e. the construct used in the kernel is only usable
> with either x86-64 or without -fPIC/-fPIE on i386.  There are ways to
> write this construct without triggering the error message, but I want to
> test the thing as written in the kernel.  So the only option besides
> disabling the test is to force non-PIC code for it on i386, which
> means for the whole file.  I've done that now on mob with a lengthy
> comment in tcctest.c.

Right, thanks for the explanation. And for the patch.

> Oh, and the testing pipeline is useful, thanks for setting it up :-)  
> (Though it would be nice if at least the native machines, i.e.
> i386 and x86-64, wouldn't use a full system emulation seemingly without
> paravirt; 8 minutes for a testrun of tcc seems a bit excessive; but as you
> said, definitely better than nothing :) )

Ok, I enabled a "test_native" job that runs tests without a virtual
machine. It is only for amd64, for the moment. I will add i386 as soon
as I have some time to test the right environment and commands.

BTW, I am happy that my experiment was, as it appears, well received. If
this is ok for you, I might add the CI files (.gitlab-ci.yml and related
scripts) to the main repository, so that everybody can fix them if
necessary, and so that the commits shown in the Gitlab interface
actually match those in the main repository. How do you find this?

Also, I have fixed my Debian image generator to use an older kernel for
riscv64, because the latest one does not boot properly. Hopefully
tomorrow (in the European sense) I will able to run a CI test also on
riscv64.

At last, Windows, which I would like to test as well. For the moment,
though, I cannot even build tcc with MinGW. I have installed MinGW
following instructions in [1], installing all the packages that seem to
be somehow relevant. However, the linker fails. Trying to compile the
program "int main(){}" gives the following errors (running "gcc test.c"):

> ld.exe: cannot find -lgcc
> ld.exe: cannot find -lgcc_eh
> ld.exe: cannot find -lgcc
> ld.exe: cannot find -lgcc_eh
> collect2.exe: error: ld returned 1 exit status

Tcc linking fails with the same error. Does anybody know what is the
problem here? It is the first time I use MinGW.

 [1] http://mingw.org/wiki/Getting_Started

I can compile on Windows using the MSVC compiler and the build-tcc.bat
script. How can I run "make test" on the executable that is produced
this way?

Thanks, Giovanni.
--
Giovanni Mascellani <[hidden email]>
Postdoc researcher - Université Libre de Bruxelles


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CI improvements (was: Re: TinyCC failure on i386)

Michael Matz-4
Hi,

On Tue, 17 Dec 2019, Giovanni Mascellani wrote:

> Ok, I enabled a "test_native" job that runs tests without a virtual
> machine. It is only for amd64, for the moment. I will add i386 as soon
> as I have some time to test the right environment and commands.

Super, thanks.

> BTW, I am happy that my experiment was, as it appears, well received. If
> this is ok for you, I might add the CI files (.gitlab-ci.yml and related
> scripts) to the main repository, so that everybody can fix them if
> necessary, and so that the commits shown in the Gitlab interface
> actually match those in the main repository. How do you find this?

Is it possible to put them in some subdir (ci/ or somesuch)?  I certainly
wouldn't mind to have them in the repo.

> Also, I have fixed my Debian image generator to use an older kernel for
> riscv64, because the latest one does not boot properly. Hopefully
> tomorrow (in the European sense) I will able to run a CI test also on
> riscv64.

Btw, for my local development I'm using user-space emulation of qemu, not
full system emulation.  (And the userspace is simply an unpacked minimal
distro of the right type, either debian or suse, in some subdir).  Makes
development a bit faster and less cumbersome as well (e.g. I don't need an
editor in that chroot, but can simply edit from the outside).  But I don't
know if that's easily/usefully possible with the CI infrastructure.
Anyway, just FYI, the CI as is is useful enough.

> At last, Windows, which I would like to test as well. For the moment,
> though, I cannot even build tcc with MinGW. I have installed MinGW
> following instructions in [1], installing all the packages that seem to
> be somehow relevant. However, the linker fails. Trying to compile the
> program "int main(){}" gives the following errors (running "gcc test.c"):

I can't say, looks like some incomplete installation of either the
compiler or some environment variables missing.  At another place I was
using msys2 (http://www.msys2.org/) and pristine cygwin successfully, I
don't remember if I ever used mingw as is.

>> ld.exe: cannot find -lgcc
>> ld.exe: cannot find -lgcc_eh
>> ld.exe: cannot find -lgcc
>> ld.exe: cannot find -lgcc_eh
>> collect2.exe: error: ld returned 1 exit status
>
> Tcc linking fails with the same error. Does anybody know what is the
> problem here? It is the first time I use MinGW.
>
> [1] http://mingw.org/wiki/Getting_Started
>
> I can compile on Windows using the MSVC compiler and the build-tcc.bat
> script. How can I run "make test" on the executable that is produced
> this way?

I think you'd at least need a make that is sufficiently GNU make
compatible for this; mingw, cygwin and friends come with it, the MSVC
toolchain also has a native make system but it's not fully compatible, and
I don't think it'd be usable.  You could of course always write another
batch file that compiles and executes the tests manually, or at least a
subset.  (E.g. tcctest.c and those in tests2/*.c).

Or just get one of the mingw derivates working ;-)

For simple checking of PE code generation I'm actually using linux and
wine:

% make cross-x86_64-win32
% ./x86_64-win32-tcc -B. -Iwin32/include/ -Iwin32/include/sys ~/hello.c \
   -Lwin32/lib/ -L.
% wine ./hello.exe
Hello World!

(This is using the uninstalled compiler) That can probably be extended
somewhat to also compile and run the testsuite via a wine wrapper.


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CI improvements (was: Re: TinyCC failure on i386)

Christian Jullien-3
In reply to this post by Giovanni Mascellani
Giovanni,

To build and test tcc on Windows you can get tcc companion https://sourceforge.net/p/wintcc/svn/HEAD/tree/  I've made
See README. I use Cygwin build to test about each commit on Windows.

C.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Giovanni Mascellani
Sent: Tuesday, December 17, 2019 19:27
To: [hidden email]
Subject: [Tinycc-devel] CI improvements (was: Re: TinyCC failure on i386)

Hi,

Il 17/12/19 18:11, Michael Matz ha scritto:
> I had now time to look into this.  The immediate cause is that new
> Debian enables PIC by default also with -m32, which triggers the error message.
> It was always there, i.e. the construct used in the kernel is only
> usable with either x86-64 or without -fPIC/-fPIE on i386.  There are
> ways to write this construct without triggering the error message, but
> I want to test the thing as written in the kernel.  So the only option
> besides disabling the test is to force non-PIC code for it on i386,
> which means for the whole file.  I've done that now on mob with a
> lengthy comment in tcctest.c.

Right, thanks for the explanation. And for the patch.

> Oh, and the testing pipeline is useful, thanks for setting it up :-)
> (Though it would be nice if at least the native machines, i.e.
> i386 and x86-64, wouldn't use a full system emulation seemingly
> without paravirt; 8 minutes for a testrun of tcc seems a bit
> excessive; but as you said, definitely better than nothing :) )

Ok, I enabled a "test_native" job that runs tests without a virtual machine. It is only for amd64, for the moment. I will add i386 as soon as I have some time to test the right environment and commands.

BTW, I am happy that my experiment was, as it appears, well received. If this is ok for you, I might add the CI files (.gitlab-ci.yml and related
scripts) to the main repository, so that everybody can fix them if necessary, and so that the commits shown in the Gitlab interface actually match those in the main repository. How do you find this?

Also, I have fixed my Debian image generator to use an older kernel for riscv64, because the latest one does not boot properly. Hopefully tomorrow (in the European sense) I will able to run a CI test also on riscv64.

At last, Windows, which I would like to test as well. For the moment, though, I cannot even build tcc with MinGW. I have installed MinGW following instructions in [1], installing all the packages that seem to be somehow relevant. However, the linker fails. Trying to compile the program "int main(){}" gives the following errors (running "gcc test.c"):

> ld.exe: cannot find -lgcc
> ld.exe: cannot find -lgcc_eh
> ld.exe: cannot find -lgcc
> ld.exe: cannot find -lgcc_eh
> collect2.exe: error: ld returned 1 exit status

Tcc linking fails with the same error. Does anybody know what is the problem here? It is the first time I use MinGW.

 [1] http://mingw.org/wiki/Getting_Started

I can compile on Windows using the MSVC compiler and the build-tcc.bat script. How can I run "make test" on the executable that is produced this way?

Thanks, Giovanni.
--
Giovanni Mascellani <[hidden email]> Postdoc researcher - Université Libre de Bruxelles



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CI improvements

grischka
In reply to this post by Giovanni Mascellani
Giovanni Mascellani wrote:
> At last, Windows, which I would like to test as well. For the moment,
> though, I cannot even build tcc with MinGW. I have installed MinGW
> following instructions in [1], installing all the packages that seem to
> be somehow relevant. However, the linker fails.

In any case to, run the scripts, a posix emulation shell is needed,
and a gcc and gnu-make, and diff for the tests.

MSYS, nowadays MSYS2 basically is a cygwin, that understands
native windows paths say, better (c:\foo as /c/foo or c:/foo)
I guess you could try a MSYS2 base from

     https://github.com/msys2/msys2/wiki/MSYS2-installation

There is a 'mingw32/64_shell.bat' to start the shell.  I wouldn't
at first update the base itself as they describe, just use as is.
To start with:

     pacman -S mingw-w64-i686-gcc (or -x86_64-)
     pacman -S make diffutils

--- grischka

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: CI improvements (was: Re: TinyCC failure on i386)

Giovanni Mascellani
In reply to this post by Michael Matz-4
Hi,

Il 17/12/19 23:57, Michael Matz ha scritto:
> Is it possible to put them in some subdir (ci/ or somesuch)?  I
> certainly wouldn't mind to have them in the repo.

Yes, no problem.

>> Also, I have fixed my Debian image generator to use an older kernel for
>> riscv64, because the latest one does not boot properly. Hopefully
>> tomorrow (in the European sense) I will able to run a CI test also on
>> riscv64.
>
> Btw, for my local development I'm using user-space emulation of qemu,
> not full system emulation.  (And the userspace is simply an unpacked
> minimal distro of the right type, either debian or suse, in some
> subdir).  Makes development a bit faster and less cumbersome as well
> (e.g. I don't need an editor in that chroot, but can simply edit from
> the outside).  But I don't know if that's easily/usefully possible with
> the CI infrastructure. Anyway, just FYI, the CI as is is useful enough.
In the CI I cannot use neither KVM nor QEMU user mode via binfmt, so I
have to use a virtual machine. Unless I manage to use QEMU user mode
without passing by binfmt, which I haven't yet investigated.

I enabled riscv64, which is currently failing:

  https://gitlab.com/giomasce/tinycc/-/jobs/383517514#L1099

I have no time to investigate this now. BTW, riscv64 is even more hacky
than other architectures due to some bugs and very in-development
things. In particular, currently the clock is wrong and there are a lot
of messages complaining about the past happening in the future, but I
hope they are harmless.

Thanks everybody for suggestions with Windows. I will do some more
experiments when I have some time.

Giovanni.
--
Giovanni Mascellani <[hidden email]>
Postdoc researcher - Université Libre de Bruxelles


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

signature.asc (235 bytes) Download Attachment