apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Proposal for 1.2 [nearing release]
Date Tue, 02 Aug 2005 15:36:35 GMT
At 05:46 AM 7/25/2005, Joe Orton wrote:
>On Fri, Jul 22, 2005 at 05:25:14PM -0500, William Rowe wrote:
>...
>>  /**
>> + * Resolve a dso pathname from a dso symbol (address) or partial name.
>> + * @param filepath The returned filepath
>> + * @param ressym A pointer to any symbol of the desired dso
>> + * @param matchfile The short name of a dso, e.g. libfoo for /usr/lib/libfoo.so.7
>> + * @param pool A pool to to allocate the resulting filepath
>> + * @remarks Some platforms will derive the loaded module directly
>> + * from the ressym given, if it is an address in that loaded module's
>> + * memory mapping.  Others don't have this facility, but may track
>> + * down filepaths from short names in the global symbol table.
>> + * Note that given the example. libfoo, if libfoo.so.3 and libfoo.so.7
>> + * are both loaded in memory, the result is not predictable.
>
>If the results of this are not reliable this doesn't seem that useful.  
>What platforms need the fuzzy matching against filenames?

The fact is; some applications will code this fuzzy-match (e.g. unwind
PATH or whatever else they have at their disposal) and such apps can't
benefit from a KNOWN binary location on those platforms which convey
this information.

Some examples include;

  * modules such as FIPS, which must find themself and do a SHA-1
    validation of the module file against a known-good signature.

  * modules such as iconv where we would like to place the iconv
    directory beside the libiconv.so, and have this iconv located
    without the added hassle of envvars.

Bill



Mime
View raw message