Re: [Tinycc-devel] x86_64: shared libs
Michael Matz wrote: Hi, On Fri, 4 Apr 2014, Michael Matz wrote: Yes, that's something on my TODO. Theoretically having runtime_plt_and_got makes code emission a tiny bit faster because having a proper PLT and GOT also for -run means first creating and second applying intermediate relocations (the _GLOB_DAT and _JUMP_SLOT relocs), which is cut short with the hack. OTOH removing the hack would remove deviation depending on output type, so I think it's a good idea nevertheless. Done now. Wow, does that look clean. Thanks ! --- grischka For x86_64 and ARM, where the latter required me to extend the current relocation support to some more cases. To test the latter I used gawk and mpfr, for which I had to add alloca support to ARM. So I'm reasonably sure that my changes don't cause regressions, but from reading the code there's still potential to fix more things (and of course to implement ARM shared libs). One of those days ... Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Fri, 4 Apr 2014, Michael Matz wrote: Yes, that's something on my TODO. Theoretically having runtime_plt_and_got makes code emission a tiny bit faster because having a proper PLT and GOT also for -run means first creating and second applying intermediate relocations (the _GLOB_DAT and _JUMP_SLOT relocs), which is cut short with the hack. OTOH removing the hack would remove deviation depending on output type, so I think it's a good idea nevertheless. Done now. For x86_64 and ARM, where the latter required me to extend the current relocation support to some more cases. To test the latter I used gawk and mpfr, for which I had to add alloca support to ARM. So I'm reasonably sure that my changes don't cause regressions, but from reading the code there's still potential to fix more things (and of course to implement ARM shared libs). One of those days ... Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Question apropos: On linux x86_64 there is still the ugly runtime_plt_and_got hack which is a replacement for PLT in the tcc -run case to forward 32bit calls to extern libraries. On win64 the same problem is solved by building the IAT (import address table) also in the -run case. From your estimation, would it be possible to do the same on ELF? That is build the PLT/GOT as if we were making an executable and then use that with tcc -run? --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Fri, 4 Apr 2014, grischka wrote: Question apropos: On linux x86_64 there is still the ugly runtime_plt_and_got hack which is a replacement for PLT in the tcc -run case to forward 32bit calls to extern libraries. On win64 the same problem is solved by building the IAT (import address table) also in the -run case. From your estimation, would it be possible to do the same on ELF? That is build the PLT/GOT as if we were making an executable and then use that with tcc -run? Yes, that's something on my TODO. Theoretically having runtime_plt_and_got makes code emission a tiny bit faster because having a proper PLT and GOT also for -run means first creating and second applying intermediate relocations (the _GLOB_DAT and _JUMP_SLOT relocs), which is cut short with the hack. OTOH removing the hack would remove deviation depending on output type, so I think it's a good idea nevertheless. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Hi, On Mon, 31 Mar 2014, Aharon Robbins wrote: Testing appreciated (hi Arnold :) ). This has certainly improved things; two tests that used to fail now pass, although two more continue to fail. If you want to test yourself, here's the recipe: git clone git://git.savannah.gnu.org/gawk.git cd gawk git checkout gawk-4.1-stable ./bootstrap.sh # due after clone or pull ./configure CC=tcc make make -k check # filefuncs and functab4 tests should fail This is really great progress, thanks! Thanks for the report. The cause is that libtcc1.a needs to contain position independend code as well (so that it may be linked into shared libraries). I've simply added -fPIC for compiling all components of it, which should be fine no matter if it's compiled by gcc or tcc. In any case the default config from tcc (mob branch as of ea2805f0) can now build gawk-4.1-stable without shared lib regressions (i.e. filefuncs and functab4 now work). I do see other tests fail as well: backbigs1, backsmalls1, mbfw1, mbprintf1 and mbprintf4; which seem to be locale dependend, but they work when compiling with gcc on my system. But seems unrelated to shared libs issues. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64: shared libs
Le 2014-03-31 11:54, Michael Matz a écrit : Hi, I just pushed some things [1] to mob that make shared libs on x86-64 linux sort of working (well, in my little tests). It's not 100% conformant to the ABI yet, but hey, its late here :) i386 could now use some cleanups as well (so that it really generates PIC code, not that unsharing text-reloc containing code it currently emits). I have checked x86-64 (no testsuite bugs) and i386 (no _additional_ testsuite bugs), but not ARM. I tried to not change the latter, although it also contains dubious code (OTOH it currently doesn't support generated shared libs at all, so ...), but I might have unintentionally broken stuff. Wow, that's great. Thanks a lot for this, I know a few users that will be happy. I had to extend struct sym_attr to contain a full plt_offset, not just a flag, it's really required. Shouldn't be too bad as it's created only for symbols that really take part in dynamic linking. Not really no because alloc_sym_attr allocates an array whose size is that of the max sym_index passed to it. This makes finding the attribute of a symbol fast, as opposed to a mailing list. A simple hashtable with helper functions would be better of course. Testing appreciated (hi Arnold :) ). I'll ping the Debian bug report for people to test you changes. Thanks again, it was a long requested feature. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] x86_64: shared libs
Hi, I just pushed some things [1] to mob that make shared libs on x86-64 linux sort of working (well, in my little tests). It's not 100% conformant to the ABI yet, but hey, its late here :) i386 could now use some cleanups as well (so that it really generates PIC code, not that unsharing text-reloc containing code it currently emits). I have checked x86-64 (no testsuite bugs) and i386 (no _additional_ testsuite bugs), but not ARM. I tried to not change the latter, although it also contains dubious code (OTOH it currently doesn't support generated shared libs at all, so ...), but I might have unintentionally broken stuff. I had to extend struct sym_attr to contain a full plt_offset, not just a flag, it's really required. Shouldn't be too bad as it's created only for symbols that really take part in dynamic linking. Testing appreciated (hi Arnold :) ). Ciao, Michael. [1] http://repo.or.cz/w/tinycc.git/commitdiff/080ad7e6 http://repo.or.cz/w/tinycc.git/commitdiff/0bd12820 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
