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
