Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Sat, 25 Nov 2017, avih wrote: You can reproduce it with Linux too. This is with Ubuntu 16.04 but I'm pretty sure it's not mandatory: Let's start from scratch after cloning and cd into the tinycc dir: Thanks for the receipt, I could reproduce it and have fixed it in mob. (At the expense of using two new flag bits, but we had 5 available anyway, and it's only until the symtab unification is done, so it's only a temporary stop-gap solution). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Sat, 25 Nov 2017, grischka wrote: .def is created automatically if an "export table" with at least one symbol (with __attribute__((dllexport))) is created for the dll or exe. This is done so for convenience and corresponds to msvc behavior which creates .exp and .lib files automatically in that case because if the module (exe/dll) exports symbols then most likely in order to be linked with other modules at some point. The observed effect - thanks to avih for the heads up - obviously comes from the abuse of sym.a.dllexport in tccasm.c. Whether there could be a similar effect from using sym.a.dllimport - less likely I'd think but maybe still possible. Ah yes, that make sense. Thanks also to avih for the reproducer receipt on linux, I can investigate now. However,... I see that end of the year we have other things to do. Therefor, as it stands now, I'm tempted to suggest to you, Michael, to wait with release for that other idea that you did mention (with single symtab for both asm and C, etc.) to grow into shape. I'm fine either way, I've started on the unification of the symtabs already, but will fix the .def file thingy separate from that. After all, no need to hurry, what do you think? My secret hope was for a christmas present (aka release) ;-) That still doesn't imply any hurry yet, but would be really nice. Hmm, let's see ... I'm fairly sure to have the .def file problem fixed later today. The symtab unification I don't know yet, perhaps end of the weekend or next week. Basically I don't want the unification to delay a release until next year, if it would have otherwise happened this year. I don't know your end of year planning of course, if this weekend was your only time slot to do a release this year I would feel bad about being the reason for a delay until next year. If we only talk about a delay of one to three weeks I'll be happy about waiting for the unification. Anyway, waiting on the .def bug now :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Michael Matz wrote: It'd be very surprising for my patch to have this effect. It affects symbol table entries, and AFAICS that doesn't influence if the .def file is generated or not. Ultimately it's created from pe_build_exports(), which itself is called when processing the first writable data section. I don't see how commit e7c71e24 could make a difference. Are you sure the .def file isn't generated by a TCC from a commit before? Otherwise I'm at a loss, and not having a Windows system I can't help much. grischka, any ideas? .def is created automatically if an "export table" with at least one symbol (with __attribute__((dllexport))) is created for the dll or exe. This is done so for convenience and corresponds to msvc behavior which creates .exp and .lib files automatically in that case because if the module (exe/dll) exports symbols then most likely in order to be linked with other modules at some point. The observed effect - thanks to avih for the heads up - obviously comes from the abuse of sym.a.dllexport in tccasm.c. Whether there could be a similar effect from using sym.a.dllimport - less likely I'd think but maybe still possible. However,... I see that end of the year we have other things to do. Therefor, as it stands now, I'm tempted to suggest to you, Michael, to wait with release for that other idea that you did mention (with single symtab for both asm and C, etc.) to grow into shape. After all, no need to hurry, what do you think? Ciao, --- grischka Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi,
On Fri, 24 Nov 2017, avih wrote:
I noticed a change at e7c71e24 ("tccasm: synch C and asm symtab tighter")
which I'm not sure is expected.
On Windows, when I build tcc using tcc with one source, a file "tcc.def" is
created at the same dir as the resulting tcc.exe, with this content:
LIBRARY tcc.exe
EXPORTS
___try__
__chkstk
__try__
_exception_code
_exception_info
To reproduce: prepare a working version of tcc for windows (this example is
with tcc 32), clone tcc, cd to its root dir, and execute:
echo '#define TCC_VERSION "0.9.27"' > config.h && path/to/tcc.exe
-DTCC_TARGET_PE -DTCC_TARGET_I386 -Iwin32 -I. -DONE_SOURCE -o tcc.exe tcc.c
And the result is that tcc.def is created alongside tcc.exe .
This started happening at e7c71e24 . The earlier commit ("Adjust testcase
for PIE compilers") doesn't create tcc.def with the same invocation.
Is it expected? a bug?
It'd be very surprising for my patch to have this effect. It affects
symbol table entries, and AFAICS that doesn't influence if the .def file
is generated or not. Ultimately it's created from pe_build_exports(),
which itself is called when processing the first writable data section. I
don't see how commit e7c71e24 could make a difference.
Are you sure the .def file isn't generated by a TCC from a commit before?
Otherwise I'm at a loss, and not having a Windows system I can't help
much. grischka, any ideas?
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Thu, 23 Nov 2017, grischka wrote: Different calling convention on win64. I'd suggest the attached version which is more platform neutral. Yup, that's better. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
I can confirm that with this version of the file the asm test (and all other tests) pass both with tcc32 and tcc64, regardless if it was built with gcc or tcc, and regardless of build/test procedure. On Thursday, November 23, 2017 10:17 PM, grischka wrote: avih wrote: > - tcc 64 fails the asm tests (again, all versions regardless of how it was > built). Different calling convention on win64. I'd suggest the attached version which is more platform neutral. -- gr > On Thursday, November 23, 2017 8:17 PM, grischka wrote: > > > 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 > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
avih wrote:
- tcc 64 fails the asm tests (again, all versions regardless of how it was
built).
Different calling convention on win64. I'd suggest the attached
version which is more platform neutral.
-- gr
On Thursday, November 23, 2017 8:17 PM, grischka wrote:
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
#include
#if defined _WIN32 && !defined __TINYC__
# define _ "_"
#else
# define _
#endif
static int x1_c(void)
{
printf("x1\n");
return 1;
}
asm(".text;"_"x1: call "_"x1_c; ret");
int main(int argc, char *argv[])
{
asm("call "_"x1");
asm("call "_"x2");
asm("call "_"x3");
return 0;
}
static
int x2(void)
{
printf("x2\n");
return 2;
}
extern int x3(void);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
> but I'm currently having some issues which I want to explore further before I > post further info. My initial inaccurate description was because my build script was skipping some tests for tcc 64, and it all passed, and the success I saw at the log was for tcc32. It didn't actually run the asm test for tcc 64. For completeness, I installed also mingw gcc 32 and tested all combinations again. TL;DR: - tcc 32 pass the asm test (all versions, built with gcc 32 or with tcc 32, with the normal build procedure or with my reproducible script). - tcc 64 fails the asm tests (again, all versions regardless of how it was built). My build script, once fixed to not skip some 64 tests, also fails the asm test with tcc 64. On Thursday, November 23, 2017 8:17 PM, grischka wrote: 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 >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 '/bld/tests' >> make: *** [Makefile:346: test] Error 2 >> >> >> On Wednesday, November 22, 2017 7:11 PM, Michael Matz >> 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 >>>
Re: [Tinycc-devel] forward asm symbols vs static
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 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 '/bld/tests' make: *** [Makefile:346: test] Error 2 On Wednesday, November 22, 2017 7:11 PM, Michael Matz 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.
Re: [Tinycc-devel] forward asm symbols vs static
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 '/bld/tests' > make: *** [Makefile:346: test] Error 2 > > > On Wednesday, November 22, 2017 7:11 PM, Michael Matz > 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 > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > >___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
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 Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi,
On Sun, 19 Nov 2017, grischka wrote:
> I admit that tccasm.c is one of the white areas on my tcc map, but
> 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 :)
Ciao,
Michael.
>
> --- grischka
>
> $ gcc -c t1.c t2.c && gcc t1.o t2.o -o t.exe && t.exe
> x1
> x2
> x3
>
> $ tcc -c t1.c t2.c && tcc t1.o t2.o -o t.exe && t.exe
> tcc: error: undefined symbol 'x1'
> tcc: error: undefined symbol 'x2'
>
> $ tcc t1.c t2.c -o t.exe && t.exe
> tcc: error: undefined symbol 'x1'
> tcc: error: undefined symbol 'x2'
>
> /***/
> /* T1.C */
>
> #include
>
> #if defined _WIN32 && !defined __TINYC__
> # define U "_"
> #else
> # define U
> #endif
>
> const char str[] = "x1\n";
> asm(U"x1: push $"U"str; call "U"printf; pop %ecx; ret");
>
> int main(int argc, char *argv[])
> {
> asm("call "U"x1");
> asm("call "U"x2");
> asm("call "U"x3");
> return 0;
> }
>
> static
> int x2(void)
> {
> printf("x2\n");
> return 2;
> }
>
> extern int x3(void);
>
>
> /***/
> /* T2.C */
>
> #include
>
> int x3(void)
> {
> printf("x3\n");
> return 3;
> }
>
> >
> >
> > Ciao,
> > Michael.
> >
>
>
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Michael Matz wrote:
Gnah, what a rats hole :-/ I found another failure mode that occurs only
when defaulting asm labels to VT_STATIC/STB_LOCAL. I don't yet want to
revert as it fixes demonstratable bugs, but OTOH I lack time tonight to
fix this third problem as well. If you want to release soon, I'd
suggest to revert d0db2175 back to a8ece0f2 (i.e. to a state where the
alloca86_64.S/p3 reoccurs, like it always had in the past). If you can
wait some more days with the release I'm going to fix it properly
(hopefully).
I already decided to delay for one more week ;)
(FWIW the problem occurs when building multiple files into one
executable (it works when compiling the files individually and then
linking the .o files together) where the files each contain multiple asm
snippets containing forward references that eventually turn out to be
global. local symbols aren't entered into the ELF hash tables and when
they are globalized later are missing from them, ultimately leading to
linker errors. At least I think that's the reason :) This is all made a
bit messy by the fact that the asm symtable lives only during one asm
snippet, which is itself messy to fix because it shares the namespace
with the C labels.)
I admit that tccasm.c is one of the white areas on my tcc map, but
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).
Below is some test that I just have tried.
--- grischka
$ gcc -c t1.c t2.c && gcc t1.o t2.o -o t.exe && t.exe
x1
x2
x3
$ tcc -c t1.c t2.c && tcc t1.o t2.o -o t.exe && t.exe
tcc: error: undefined symbol 'x1'
tcc: error: undefined symbol 'x2'
$ tcc t1.c t2.c -o t.exe && t.exe
tcc: error: undefined symbol 'x1'
tcc: error: undefined symbol 'x2'
/***/
/* T1.C */
#include
#if defined _WIN32 && !defined __TINYC__
# define U "_"
#else
# define U
#endif
const char str[] = "x1\n";
asm(U"x1: push $"U"str; call "U"printf; pop %ecx; ret");
int main(int argc, char *argv[])
{
asm("call "U"x1");
asm("call "U"x2");
asm("call "U"x3");
return 0;
}
static
int x2(void)
{
printf("x2\n");
return 2;
}
extern int x3(void);
/***/
/* T2.C */
#include
int x3(void)
{
printf("x3\n");
return 3;
}
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Sun, 19 Nov 2017, Michael Matz wrote: Aha! Indeed, p3 should be STB_LOCAL, and now (after my revert or before your patch) isn't anymore. Okay, I'll work on this. Need to find a way to get both things working, hmm :) Fixed in mob. Gnah, what a rats hole :-/ I found another failure mode that occurs only when defaulting asm labels to VT_STATIC/STB_LOCAL. I don't yet want to revert as it fixes demonstratable bugs, but OTOH I lack time tonight to fix this third problem as well. If you want to release soon, I'd suggest to revert d0db2175 back to a8ece0f2 (i.e. to a state where the alloca86_64.S/p3 reoccurs, like it always had in the past). If you can wait some more days with the release I'm going to fix it properly (hopefully). (FWIW the problem occurs when building multiple files into one executable (it works when compiling the files individually and then linking the .o files together) where the files each contain multiple asm snippets containing forward references that eventually turn out to be global. local symbols aren't entered into the ELF hash tables and when they are globalized later are missing from them, ultimately leading to linker errors. At least I think that's the reason :) This is all made a bit messy by the fact that the asm symtable lives only during one asm snippet, which is itself messy to fix because it shares the namespace with the C labels.) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Fri, 17 Nov 2017, Michael Matz wrote: Aha! Indeed, p3 should be STB_LOCAL, and now (after my revert or before your patch) isn't anymore. Okay, I'll work on this. Need to find a way to get both things working, hmm :) Fixed in mob. Btw. my current 0.9.27 release plan is to do it as soon as I have time, using basically the current state of code (with one last commit). Is there something that you're currently working that would be a reason wait some more time? Nope. In fact I have a couple things in various branches where I was waiting for the release to happen, as I wanted to not disrupt stuff before. But I think the above p3 problem should be fixed first. So, ship it! ;-) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Hi, On Thu, 16 Nov 2017, grischka wrote: > Except ... there was one text relocation which at first I could not > explain where it comes from but then with some objdumps I found it > was a relocation to the 'p3' label in libtcc1.a:alloca86_64.s which > defeated my efforts to get rid of DT_TEXTREL (at least for a self- > compiled tcc at least on x86_64, that is). See here > > /* alloca86_64.S */ > .globl alloca > > alloca: > pop %rdx > ... > jz p3 > ... > p3: > push%rdx > ret > > Now I would think that 'p3' neither is global nor is undefined and > therefor should not be placed in dynsym and even less with a non-pc- > relative relocation. The only thing that is particular about p3 > (say in contrast to p1 and p2) is that it is a forward label. Aha! Indeed, p3 should be STB_LOCAL, and now (after my revert or before your patch) isn't anymore. Okay, I'll work on this. Need to find a way to get both things working, hmm :) > Btw. my current 0.9.27 release plan is to do it as soon as I have > time, using basically the current state of code (with one last commit). > Is there something that you're currently working that would be a reason > wait some more time? Nope. In fact I have a couple things in various branches where I was waiting for the release to happen, as I wanted to not disrupt stuff before. But I think the above p3 problem should be fixed first. Perhaps later today or tomorrow. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] forward asm symbols vs static
Forgot to mention the actual benefit from my former change:
It was (IIRC) to allow the dlltest test pass on musl. (That is
to use tcc on x86_64 to create a libtcc.so without DT_TEXTREL)
-- gr
grischka wrote:
Michael Matz wrote:
Hello grischka,
I had to revert a small part of your da8c62 commit ("various stuff"):
tccasm.c:
- keep forward asm labels static, otherwise they will endup
in dynsym eventually.
A symbol which stays undefined until the end is implicitely
STB_GLOBAL, even without a .globl directive. I've added a testcase to
that effect. Before just reverting the hunk I've tried to move it
somewhere else in order not to lose the effect mentioned above.
But in the end I wasn't really successful in constructing a testcase
where such symbol ends up in dynsym when it shouldn't. E.g. local
labels (the numeric ones) are always already constructed as
VT_STATIC. And normal labels are also created VT_STATIC, except if
they already were associated with a .globl directive. So I don't
really see how the problem above could have happened.
To recollect, give the following assembler snippet:
jmp 1f
local:
call local
call undefined
call global
.globl global
global:
1: nop
the symbols L..1 and local need to be STB_LOCAL, while undefined and
global need to be STB_GLOBAL.
So, if you have a testcase or remember the situation that you tried to
fix, can you tell me which one it was? :)
Yes. The long story is:
I was messing with Alpine/musl, which prefers relocatable executables,
for which to produce I have a patch which basically is no big deal
(just going the OUTOUT_DLL path and adding some aspects of exes).
But..., of course then musl doesn't like to see DT_TEXTREL in such
executables (or dll's either).
So I did not commit this patch for now (because I didn't really have
the intention to add full PIC support maybe for all platforms). However
I made it so that DT_TEXTREL is set only when needed.
Now, since x86_64 supports pc-relative data addresses, at least
for tcc itself it is possible to avoid DT_TEXTREL (and hence to
create a fully musl compliant relocatable tcc executable if wanted).
Except ... there was one text relocation which at first I could not
explain where it comes from but then with some objdumps I found it
was a relocation to the 'p3' label in libtcc1.a:alloca86_64.s which
defeated my efforts to get rid of DT_TEXTREL (at least for a self-
compiled tcc at least on x86_64, that is). See here
/* alloca86_64.S */
.globl alloca
alloca:
pop %rdx
...
jz p3
...
p3:
push%rdx
ret
Now I would think that 'p3' neither is global nor is undefined and
therefor should not be placed in dynsym and even less with a non-pc-
relative relocation. The only thing that is particular about p3
(say in contrast to p1 and p2) is that it is a forward label.
Sorry for messing up your test cases, I was aware that there is some
chance that it would. Also, if you can find some solution for the
problem above, would be great.
Btw. my current 0.9.27 release plan is to do it as soon as I have
time, using basically the current state of code (with one last commit).
Is there something that you're currently working that would be a reason
wait some more time?
Ciao,
--- grischka
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] forward asm symbols vs static
Hello grischka,
I had to revert a small part of your da8c62 commit ("various stuff"):
tccasm.c:
- keep forward asm labels static, otherwise they will endup
in dynsym eventually.
A symbol which stays undefined until the end is implicitely STB_GLOBAL,
even without a .globl directive. I've added a testcase to that effect.
Before just reverting the hunk I've tried to move it somewhere else in
order not to lose the effect mentioned above.
But in the end I wasn't really successful in constructing a testcase where
such symbol ends up in dynsym when it shouldn't. E.g. local labels (the
numeric ones) are always already constructed as VT_STATIC. And normal
labels are also created VT_STATIC, except if they already were associated
with a .globl directive. So I don't really see how the problem above
could have happened.
To recollect, give the following assembler snippet:
jmp 1f
local:
call local
call undefined
call global
.globl global
global:
1: nop
the symbols L..1 and local need to be STB_LOCAL, while undefined and
global need to be STB_GLOBAL.
So, if you have a testcase or remember the situation that you tried to
fix, can you tell me which one it was? :)
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
