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

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Feb 15 21:40:26 CET 2011


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';

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

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.

> 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.


Jonas


More information about the fpc-devel mailing list