[Top][All Lists]

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

Re: [Tinycc-devel] Support for hidden symbols?

From: Michael Matz
Subject: Re: [Tinycc-devel] Support for hidden symbols?
Date: Mon, 14 Apr 2014 05:22:59 +0200 (CEST)
User-agent: Alpine 2.00 (LNX 1167 2008-08-23)


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 )
        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?


reply via email to

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