tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] forward asm symbols vs static


From: grischka
Subject: Re: [Tinycc-devel] forward asm symbols vs static
Date: Thu, 23 Nov 2017 19:17:23 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

I've seen a segfault under some other circumstances on linux 64.

Using "lea str(%rip),%rdi" instead of "mov $str,%rdi" in asm-c-connect-1.c
did fix it.  (I can't tell right now whether that is expected behavior or
points to a bug though.)

Also I noticed that apparently 'U' is a string prefix in newer gcc versions.
(Don't know, maybe for unicode?).

Btw, what about the "vide" hack on tccasm.c:1020 from commit 6afe668ec
Can we delete it?

Ciao,

--- grischka

avih wrote:
The test is always compiled by tcc.
Of course.

So if you say "initial compiler", do you mean the compiler by which tcc itself 
is compiled?
Yes
I.e. there is a difference if tcc is compiled by gcc (tcc produces segfaulting> 
code then), vs. with tcc (the resulting tcc produces good code)?
That's what I said indeed, but apparently there's more to it.
First, attached are the .o files from the two c files, each compiled with three 
different versions of tcc, two of those were compiled themselves using tcc 
(tcc32-tcc32 and tcc64-tcc64), and one version of tcc compiled using gcc 
(gcc64-tcc64).
There's no difference at the .o files between the tcc64-tcc64 versions to the 
gcc64-tcc64 versions. I don't have gcc32 installed to create gcc32-tcc32 .o 
file and compare to the tcc32-tcc32 .o version, but I've attached the 
tcc32-tcc32 version anyway.
So it must be at the build/test procedure.
If I use the standard (out of tree) build with ../configure && make && make 
test then indeed it fails the same way (segfault) regardless if I'm building tcc with gcc or 
with tcc (i.e. ../configure --cc=/abs/path/to/tcc.exe ...).
But when I reported my results earlier I used a different build+test  procedure 
for tcc-tcc which succeeded - at least apparently, with the output I reported 
at the previous mail.
The one which succeeded was using my reproducible build script which runs the 
tests makefile with custom arguments, but I'm currently having some issues 
which I want to explore further before I post further info.
If anyone else could try building tcc using mingw gcc (32 and/or 64) using the 
normal procedure and running the tests, it could help.


    On Thursday, November 23, 2017 3:58 PM, Michael Matz <address@hidden> wrote:
 Hi,

On Thu, 23 Nov 2017, avih wrote:

I hope it also works on win32 and win64, which I haven't tested
asm-c-connect-test pass if the initial compiler is tcc 32 or 64 (and building 
tcc 32/64 respectively).
It segfaults if the initial compiler is gcc 64 (mingw gcc 7.2.0, in msys2 
setup).
I didn't test with gcc 32 mingw.

The test is always compiled by tcc. So if you say "initial compiler", do you mean the compiler by which tcc itself is compiled? I.e. there is a difference if tcc is compiled by gcc (tcc produces segfaulting code then), vs. with tcc (the resulting tcc produces good code)?

Hmpf.

Can you compile the two files separately into .o files and attach them here? (With the failing compiler I mean). Perhaps it's something obvious, but I can't test win32/64.


Ciao,
Michael.

When it passes, this is what it prints:------------ asm-c-connect-test 
------------
./asm-c-connect
x1
x2
x3
And when it fails:../tcc.exe -B../../win32 -I../../include -I../.. -I.. -L.. -o 
asm-c-connect.exe ../../tests/asm-c-connect-1.c ../../tests/asm-c-connect-2.c
------------ asm-c-connect-test ------------
./asm-c-connect.exe
make[1]: *** [Makefile:240: asm-c-connect-test] Segmentation fault
make[1]: Leaving directory '<tcc-root>/bld/tests'
make: *** [Makefile:346: test] Error 2
    On Wednesday, November 22, 2017 7:11 PM, Michael Matz <address@hidden> 
wrote:
  Hi,

On Mon, 20 Nov 2017, Michael Matz wrote:

naively I'd think that it probably should more closely emulate the gcc situation where inline asm ends up just as embedded snippets in its C -> asm output. Which could mean for example that "free_asm_labels" should be called only once at the end of each "translation unit" (file).
Yes, that would be the ultimate goal. As said, this would elevate the problem of sharing C-label and asm-label namespace, which already is a problem right now, even more. So that needs solving, preferably without needing too much additional memory, then the move to a single end-of-file free_asm_labels, and then all is sunny :)

Below is some test that I just have tried.
Yep, a conscise example of all asm- symbol table problems we have right now :)
I've fixed the problems I know about, including this two-file testcase (I've added it to the testsuite, I hope it also works on win32 and win64, which I haven't tested).

After release I'm probably going to change how the asm symtable is implemented, which then does away with the new slot in TokenSym. My idea is to have just a single sym table for global decls, the C one, which can be used for the asm one as well, with some slight adjustments.

But as is, it at least fixes the testcase, the linux-2.4.x 32bit kernel, and 64bit linux 4.6, so I'm happy enough for now :)


Ciao,
Michael.

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




------------------------------------------------------------------------

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]