On Sun, Apr 13, 2014 at 8:22 PM, Michael Matz <[email protected]> wrote:
> Hi, > > > On Sat, 12 Apr 2014, Austin English wrote: > > I recently revisited compiling Wine with TinyCC. I've got some patches for >> wine for that, but my current blocker is a lack of support for hidden >> symbols on tcc: >> > > Even with that fixed I'll predict some more blockers for wine. It's not > exactly one of the most trivial (and C conformant) program packages. And > well, wine has some quite performance critical components, so what would be > the point in compiling it with tcc? (except for the obvious one of that > being an intellectually entertaining experiment) > > acledit.pEPjUb.s:14: error: unknown assembler directive '.hidden' >> > > Okay, so that's supporting (parsing) hidden directive from the assembler > itself. While fixing this is easy, you'll hit many more roadblocks in > actually compiling real assembler sources (the above seems to be something > emitted by the ../../tools/winegcc/winegcc wrapper). TCCs included > assembler really isn't much GAS compatible and misses many more directives. > > /* return a global symbol declaration for an assembly symbol */ >> const char *asm_globl( const char *func ) >> default: >> buffer = strmake( "\t.globl %s\n\t.hidden %s\n%s:", func, func, >> func >> ); >> >> is there any plan for supporting this? >> > > There are multiple aspects for supporting hidden symbols: 1) parsing the > above (inline) assembler directives. 2) parsing hidden symbols via > gcc-compatible visibility attribute. 3) supporting hidden symbol in the > builtin link editor. I've done 1) and 2) in the mob branch (e69c506). > > For 3) there's some code that isn't fully working yet. For x86-64 I've at > least implemented correct resolutions of calls to hidden functions. I > haven't yet implemented the other archs or correctly handling hidden data > symbols. The latter will simply be emitted as non-hidden global symbols > (even if they were hidden in the input .o files) right now. > > grischka: the PE port uses the st_other member of ELF symbols for tracking > its own IMPORT/EXPORT directives. As I'm now using it for symbol > visibility (with values 0-3) this might clash: using visibility attribute > might overwrite former IMPORT/EXPORT directives, and using IMPORT/EXPORT > might influence the ELF linker (as it will now make more use of > visibility). I lack the necessary pieces to check on windows. If there's > indeed an interaction (I can't quite figure that out from just reading the > code) but the PE port wants to continue using the st_other member (and not > the TCC symbols type) I would guess it's best to use bits outside of mask > ELFXX_ST_VISIBILITY (0x3). > > The COFF port (used for C67) is now a bit more broken than before. It > uses st_other for debug type info (ugh!). Is anyone even working on that? > Time to remove it maybe? > > > Ciao, > Michael. > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > I expected that wine wouldn't immediately work, I'm doing it for the curiosity factor. The next problem is: make[1]: Entering directory `/home/austin/src/wine-tcc/dlls/acledit' /home/austin/tcc/bin/i386-linux-gnu-tcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -g -o main.o main.c ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -shared ./acledit.spec main.o -o acledit.dll.so ../../libs/port/libwine_port.a acledit.UgAqPb.s:14: error: unknown assembler directive '.L__wine_spec_rva_base' winebuild: /home/austin/tcc/bin/i386-linux-gnu-tcc failed with status 1 winegcc: ../../tools/winebuild/winebuild failed make[1]: *** [acledit.dll.so] Error 2 -- -Austin
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
