apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Proposal for 1.2 [nearing release]
Date Mon, 25 Jul 2005 10:46:09 GMT
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?

joe

Mime
View raw message