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

[Michael Matz]

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.