Bug #0021680: Mixup of library imported/exported function names

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug #0021680: Mixup of library imported/exported function names

patspiper
The following is related to bug #0021680:

The idea is to let libraryB intercept calls to libraryA.

1- How can this be accomplished in Linux?
Using ordinals would have been a way, but Linux does use them.

Another venture (to be tested yet) may be dynamic loading of libraryA.

2- Does this mechanism take place even when the function is imported
under another name?
function functionB: char; stdcall;
             external 'sharedlibrarya'
             name 'functionA';

3- Should there be a warning about the name hiding?

4- The link http://blogs.embarcadero.com/eboling/2010/02/16/5656 
mentions: 'The linux support is a major PITA to implement'. Does that
refer to implementing a non flat namespace linker model? In other words,
difficult but not impossible?

Stephano
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug #0021680: Mixup of library imported/exported function names

Jonas Maebe-2

On 08 Apr 2012, at 21:56, patspiper wrote:

> The following is related to bug #0021680:
>
> The idea is to let libraryB intercept calls to libraryA.
>
> 1- How can this be accomplished in Linux?
> Using ordinals would have been a way, but Linux does use them.
>
> Another venture (to be tested yet) may be dynamic loading of libraryA.

That is indeed possible. You can LoadLibrary() the particular library you want (even if it has already been loaded implicitly by your program), and then look for the symbol using the handle for that particular library.

> 2- Does this mechanism take place even when the function is imported under another name?
> function functionB: char; stdcall;
>            external 'sharedlibrarya'
>            name 'functionA';

The mechanism operates at the level of the symbol name in the library. So if there are multiple symbols with the name 'functionA', then things will get mixed up. The Pascal name is irrelevant, except to the extent that it influences the symbol name if you do not explicitly

> 3- Should there be a warning about the name hiding?

The compiler cannot warn about this because this is completely handled by the linker.

> 4- The link http://blogs.embarcadero.com/eboling/2010/02/16/5656 mentions: 'The linux support is a major PITA to implement'. Does that refer to implementing a non flat namespace linker model? In other words, difficult but not impossible?

The compiler could always mangle the name, just like it does for units (of course, that would make it a major PITA to use such symbols from e.g. C code). But there is currently no support in the compiler to tell it to import an identifier from another library and to mangle it as if it were declared by Pascal code in a library/unit called 'module_something' (where it was originally declared by in other library).


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug #0021680: Mixup of library imported/exported function names

patspiper
On 08/04/12 23:12, Jonas Maebe wrote:
On 08 Apr 2012, at 21:56, patspiper wrote:

The following is related to bug #0021680:

The idea is to let libraryB intercept calls to libraryA.

1- How can this be accomplished in Linux?
Using ordinals would have been a way, but Linux does use them.

Another venture (to be tested yet) may be dynamic loading of libraryA.
That is indeed possible. You can LoadLibrary() the particular library you want (even if it has already been loaded implicitly by your program), and then look for the symbol using the handle for that particular library.

I have just tested it successfully!

      
2- Does this mechanism take place even when the function is imported under another name?
function functionB: char; stdcall;
           external 'sharedlibrarya'
           name 'functionA';
The mechanism operates at the level of the symbol name in the library. So if there are multiple symbols with the name 'functionA', then things will get mixed up. The Pascal name is irrelevant, except to the extent that it influences the symbol name if you do not explicitly 

3- Should there be a warning about the name hiding?
The compiler cannot warn about this because this is completely handled by the linker.
The compiler knows that functionA is there twice in sharedlibraryB:

function functionB: char; stdcall;
           external 'sharedlibrarya'
           name 'functionA';

and

function functionA: char; stdcall;
begin
  Result := functionB;
end;

Since the linker behaviour is predictable under all platforms, can't the compiler emit a warning?

      
4- The link http://blogs.embarcadero.com/eboling/2010/02/16/5656 mentions: 'The linux support is a major PITA to implement'. Does that refer to implementing a non flat namespace linker model? In other words, difficult but not impossible?
The compiler could always mangle the name, just like it does for units (of course, that would make it a major PITA to use such symbols from e.g. C code). But there is currently no support in the compiler to tell it to import an identifier from another library and to mangle it as if it were declared by Pascal code in a library/unit called 'module_something' (where it was originally declared by in other library).
That's too bad as Pascal should prevent you from shooting yourself in the foot ;)

Thanks,
Stephano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal