OSL API for in memory search for (ascii) function symbols

[Oliver Braun]

Hi,

as using <dlfcn.h> functions directly (without generating warnings) has
become quite ugly (double casts) and even the Windows API for searching
function symbols does not take UTF-16 arguments, I propose the following
API additions to osl/module.h:

/** Retrieve the handle of an already loaded module.

    This function can be used to search for a function symbol in the
process space.
    Do not use the returned handle as an argument of osl_unloadModule.
On Unix platforms,
    strModuleName gets ignored and the special handle RTLD_DEFAULT is
always returned.
   
    @param strModuleName
    [in] denotes the name of the module to search for. Ignored on Unix
   
    @return
    NULL if the module could not be found, otherwise a handle to the
module or the special
    RTLD_DEFAULT on Unix. NOTE: do not call osl_unloadModule on the
returned handle !
   
    @see osl_getAsciiFunctionSymbol
*/
oslModule SAL_CALL osl_getModuleHandle(rtl_uString *strModuleName);

/** Lookup the specified function symbol name.

    osl_getAsciiFunctionSymbol is an alternative function for
osl_getFunctionSymbol.
    It expects the C-style function name string to contain ascii
characters only.

    @param Module
    [in] a module handle as returned by osl_loadModule or
osl_getModuleHandle

    @param pFunctionSymbolName
    [in] Name of the function that will be looked up.
 
    @return
    <dl>
    <dt>Function address.</dt>
    <dd>on success</dd>
    <dt>NULL</dt>
    <dd>lookup failed or the parameter are invalid.</dd>
    </dl>
 
    @see osl_getModuleHandle
    @see osl_getFunctionSymbol
*/
oslGenericFunction SAL_CALL osl_getAsciiFunctionSymbol( oslModule
Module, const sal_Char *pFunctionSymbolName );

Feedback/Nitpicking  welcome !
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Philipp Lohmann]

Oliver Braun wrote:
> Hi,
>
> as using <dlfcn.h> functions directly (without generating warnings) has
> become quite ugly (double casts) and even the Windows API for searching
> function symbols does not take UTF-16 arguments, I propose the following
> API additions to osl/module.h:

>    NULL if the module could not be found, otherwise a handle to the
> module or the special
>    RTLD_DEFAULT on Unix. NOTE: do not call osl_unloadModule on the
> returned handle !

RTLD_DEFAULT is "((void *) 0)" on Linux, so this would be hard to
distinguish from NULL. -1 on the other hand is RTLD_NEXT, so perhaps we
should use another invalid pointer value to show failure. Or perhaps the
API should look like

sal_Bool CALL osl_getModuleHandle(rtl_uString *strModuleName, oslModule*
pResult );

where the return value details success/failure and the result is
returned via the second parameter.

Just my 2 cents, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
     -- Author unknown

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Oliver Braun]

Hi Philipp,

Philipp Lohmann - Sun Germany wrote:
> RTLD_DEFAULT is "((void *) 0)" on Linux, so this would be hard to
> distinguish from NULL.
Good point. I only checked Solaris, where it is  defined as "(void *)-2".

>  -1 on the other hand is RTLD_NEXT, so perhaps we
> should use another invalid pointer value to show failure. Or perhaps the
> API should look like
>
> sal_Bool CALL osl_getModuleHandle(rtl_uString *strModuleName, oslModule*
> pResult );
>
> where the return value details success/failure and the result is
> returned via the second parameter.
>  

Since osl_getModuleHandle simply can not fail on unix, another option
would be to always return '-1'  and map this to RTLD_DEFAULT in
osl_getAsciiFunctionSymbol.

What do you think ?

Thanks,
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Philipp Lohmann]

Hi,

Oliver Braun wrote:

> Hi Philipp,
>
> Philipp Lohmann - Sun Germany wrote:
>> RTLD_DEFAULT is "((void *) 0)" on Linux, so this would be hard to
>> distinguish from NULL.
> Good point. I only checked Solaris, where it is  defined as "(void *)-2".
>>  -1 on the other hand is RTLD_NEXT, so perhaps we
>> should use another invalid pointer value to show failure. Or perhaps the
>> API should look like
>>
>> sal_Bool CALL osl_getModuleHandle(rtl_uString *strModuleName, oslModule*
>> pResult );
>>
>> where the return value details success/failure and the result is
>> returned via the second parameter.
>>  
> Since osl_getModuleHandle simply can not fail on unix, another option
> would be to always return '-1'  and map this to RTLD_DEFAULT in
> osl_getAsciiFunctionSymbol.
>
> What do you think ?

Well, that happens to be RTLD_NEXT on Linux. This would not be a problem
currently, but could become insurmountable if we ever want to use
RTLD_NEXT. I suggest separating returned handle and and error handling;
IMHO the sal_Bool (rtl_uString*,oslModule*) is the right thing to do.

Kind regards, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
     -- Author unknown

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Oliver Braun]

Philipp Lohmann - Sun Germany wrote

>> Since osl_getModuleHandle simply can not fail on unix, another option
>> would be to always return '-1'  and map this to RTLD_DEFAULT in
>> osl_getAsciiFunctionSymbol.
>>
>> What do you think ?
>>    
>
> Well, that happens to be RTLD_NEXT on Linux. This would not be a problem
> currently, but could become insurmountable if we ever want to use
> RTLD_NEXT. I suggest separating returned handle and and error handling;
> IMHO the sal_Bool (rtl_uString*,oslModule*) is the right thing to do.
>  

I probably wasn't clear enough. I meant something like (pseudo code):

oslModule osl_getModuleHandle(rtl_uString *) { return -1; };


oslFunctionSymbel getAsciiFunctionSymbol(oslModule module, const
sal_Char *sym) {
    if( module == -1 )  module = RTLD_DEFAULT;
   [..]
}


The updated description would be:

    This function can be used to search for a function symbol in the
process space.
    Do not use the returned handle as an argument of osl_unloadModule.
On Unix platforms,
    strModuleName gets ignored and the special handle ((void *) -1) is
returned, which is
    treated as RTLD_DEFAULT by osl_getFunctionSymbol and
osl_getAsciiFunctionSymbol.
   
    @param strModuleName
    [in] denotes the name of the module to search for. Ignored on Unix
   
    @return
    NULL if the module could not be found, otherwise a handle to the
module or the
    special handle '((void *) -1)'on Unix.
    NOTE: do not call osl_unloadModule on the returned handle !

Thanks,
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Matthias Huetsch]

Hi Oliver,

Oliver Braun wrote:

> Philipp Lohmann - Sun Germany wrote
>
>>> Since osl_getModuleHandle simply can not fail on unix, another option
>>> would be to always return '-1'  and map this to RTLD_DEFAULT in
>>> osl_getAsciiFunctionSymbol.
>>>
>>> What do you think ?
>>
>> Well, that happens to be RTLD_NEXT on Linux. This would not be a problem
>> currently, but could become insurmountable if we ever want to use
>> RTLD_NEXT. I suggest separating returned handle and and error handling;
>> IMHO the sal_Bool (rtl_uString*,oslModule*) is the right thing to do.
>
> I probably wasn't clear enough.

I think, your initial proposal was clear. But I also think that
Philipp's approach is indeed the way to go:

Across the various platforms there appears to exist no special value
that could reliably indicate an invalid oslModuleHandle. Thus, another
means for signaling success or failure is needed, and the API proposed
by Philipp does exactly that.

sal_Bool
SAL_CALL osl_getModuleHandle(
   [in]  rtl_uString * pName,
   [out] oslModuleHandle * pHandle
);

where [out] pHandle would only be valid (regardless of its value), if
the function returns TRUE.

> I meant something like (pseudo code):
> [...]

Just my 2 cents,
Matthias

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Oliver Braun]

Hi Matthias et al.,

Matthias Huetsch wrote:

> Across the various platforms there appears to exist no special value
> that could reliably indicate an invalid oslModuleHandle. Thus, another
> means for signaling success or failure is needed, and the API proposed
> by Philipp does exactly that.
>
> sal_Bool
> SAL_CALL osl_getModuleHandle(
>   [in]  rtl_uString * pName,
>   [out] oslModuleHandle * pHandle
> );
>
> where [out] pHandle would only be valid (regardless of its value), if
> the function returns TRUE.

As we do not necessarily have to use the OS handle directly as
oslModule, we could define NULL to be an invalid oslModule handle (as we
do for osl_loadModule).

The problem with my proposal (as I see it) is more that any value we
choose for the OSL version of RTLD_DEFAULT could - in theory - also get
returned by dlopen. So I agree that the API proposed by Philipp is the
way to go, even though I need to remove some != NULL asserts in the code
for this.

As I do not plan to add getModuleHandle API to the C++ wrapper, should I
move the != NULL asserts here ?

Oliver


---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...