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'];
begin
end;
function xxx: cint; [public, alias: 'xxx'];
begin
end;
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)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
