[fpc-devel] Proposal: Supporting initial references for weakexternal

Jeppe Johansen jepjoh2 at es.aau.dk
Wed Feb 16 00:42:48 CET 2011

Den 15-02-2011 21:40, Jonas Maebe skrev:
> On 15 Feb 2011, at 20:13, Jeppe Johansen wrote:
>> Den 15-02-2011 19:31, Jonas Maebe skrev:
>>> I don't understand why you again propose to change the meaning of "external name 'xxx'" for weak symbols. As I mentioned in my previous mail, for consistency reasons something like that will not be done. I also don't see the advantage of inventing a new syntax ("weak default") when existing modifiers can already express the required semantics.
>> I don't propose changes.
> "external name 'xxx'" means more or less the same as "__attribute__((alias "xxx"))" in gcc (it's slightly different, because in gcc the "xxx" must be a symbol known to the compiler at compile time):
> 1) aliased external declaration
> in gcc:
>    extern int test(void) __attribute__((alias ("xxx")));
> in fpc:
>    function test: cint; cdecl; external name 'xxx';
> 2) regular weak external declaration
> in gcc:
>    extern int test(void) __attribute__((weak));
> in fpc:
>    function test: cint; cdecl; weak; external;
> 3) aliased weak external declaration
> in gcc:
>    extern int test(void) __attribute__((weak, alias ("xxx")));
> in fpc:
>    function test: cint; cdecl; weak; external name 'xxx';
I suppose you mean weakexternal in those examples, or are they just 
examples of an ideal future case?
> While keeping the first two points the same, you propose to make this third case in fpc, :
>    function test: cint; cdecl; weak default 'xxx';
> or
>    function test: cint; weak default 'xxx'; external name 'test'; // not entirely correct, on several platforms this should be '_test' instead
That is precisely what I propose. I think that in the low-level cases 
where I think this feature is beneficial, it's enough to have control 
over names with the "external name" directive
> This changes the meaning of "external" when combined with "weak", since it no longer specifies the external symbol to which this particular declaration refers. Please look at it from the standpoint of high level language semantics, not based on the assembler level implementation on ELF platforms.
Nothing is changed. Absolutely nothing is changed in the way external works

function testimpl: cint; [public, alias: 'test'];

function xxx: cint; [public, alias: 'xxx'];

function test1: cint; external name 'test';
function test2: cint; weak default 'xxx'; external name 'test';
function test3: cint; weak default 'xxx'; external name 'notest';

test1 and test2 call testimpl, and test3 call xxx

I don't know what you mean about the high level semantics.
>> You might also note the problem in the example
>>    //  a) on Linux
>>    //   .weak P$TestProc
>>    //   .set  P$TestProc, NoHandler
>>    //   .weak TestProc
>>    //   .set  TestProc, NoHandler
>> If you then somewhere else defines TestProc, then yes, calls to the assembler symbol TestProc will resolve to TestProcHandler. But if you call TestProc directly, in the pascal sense, then it would call P$TestProc which hasn't been overriden and thus points to NoHandler
> That's correct, so allowing "alias" in combination with "weak; external;" is probably not a good idea. Requiring cdecl is probably the best way, although I'm not sure yet what to do with non-external weak definitions then, because the symbol names of non-external cdecl routines are normally not mangled C-style by the compiler (after all, nothing prevents you from having overloaded routines that all use the cdecl calling convention). If "public" or "export" is added to a cdecl declaration, then the C-style mangled name is added as an alias, but that's not good enough here because it suffers from the same problem (Pascal-level calls to the routine will use the Pascal-mangled name rather than the C-style mangled one).
> Only setting the C-style mangled name in case of "cdecl; weak;" non-external definitions is a possibility, but it's not very nice because it's inconsistent with normal operation.
I don't think forcing cdecl is a good idea. I think the optimal case 
would be that weak procedures should just be called by their real name 
in the default calling convention. I know this is a bit hard to 
implement(I still haven't found out where that magic happens)

More information about the fpc-devel mailing list