Re: [Tinycc-devel] Unify C and asm symbols

[Michael Matz]

Hi,

On Sun, 10 Dec 2017, grischka wrote:

> May I suggest however to keep doing the asm-label undef->non-static
> conversion on the sym-stack (per file) level, because for one it is
> more obvious at what we're doing and why, and also because otherwise
> is is not correct for static C symbols, which must be defined in the
> same file or are errors otherwise.

I thought about this, but actually I was quite happy to see that 
asm-tccgen connection go.  Then I remembered that GCC works the same 
(even in pedantic c99 mode):

% cat undef-local.c
static int printf(const char *, ...);
main() { printf("hello\n"); }
% gcc -c undef-local.c
undef-local.c:1:13: warning: ‘printf’ used but never defined
 static int printf(const char *, ...);
% readelf -sW undef-local.o | grep local
     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf

(sure, there's a warning, but it's not an error).  That's no big wonder as 
GCC uses intermediate assembler files and there undefed locals become 
global.  I think doing the same in TCC is reasonable.  Maybe even 
required, as otherwise the above (questionable) program works with GCC 
(with a warning) but not TCC.

> You could push first the combined final result of the asm related
> patches, (possibly including the suggestion from above), as one
> single commit (under your authorship).

Credit where credit is due :) Pushed as three separate commits (without 
the suggestion above), your two with the commit message and authorship 
extracted from your commits in the mail.

> I'd then push the "type redefinition check" patch, including a minor
> fix (as attached) that is meant to make sure that
> - a transition global->static can never happen
> - a transition static->global can happen, but only for symbols
>  that (initially) come from asm.

Yeah, that'd be nice.  As long as for the C symbols the last transition is 
still allowed (and static wins, so in ELF symbol terms it's not really a 
transition).  Your patch seems to do the right thing here.

> I'd then make one more commit with other small fixes, and then I'd pack 
> the release, say next Sun (17.12.)
>
> How does that sound?

Quite wonderful methinks, would be awesome :)


Ciao,
Michael.