[RFC PATCH 1/2] dlfcn: add long double redirect wrappers for dl*sym
Paul E Murphy
Mon Jun 8 15:08:17 GMT 2020
On 6/5/20 9:33 AM, Joseph Myers wrote:
> These are certainly not the only functions for which there are
> header-based redirections depending on the options with which code is
> compiled, and nor is dlsym the only place with a use for such information
> about naming (the issue also applies to function calls from non-C
> languages, where GCC may need to know the name to handle built-in function
> calls correctly). I wonder if there is some better way to automate
> extraction of information from the headers of what the redirections are,
> that both avoids duplicating a long list of function names and avoids
> needing to special-case one subset of redirections for dlsym.
We can try to make the C runtime play better. There isn't much I can
directly do for other projects which implement their own runtime, but
they will need to consider some non-trivial strategy if they wish to
support the IEEE128 format leveraging glibc.
There are a few other symbols which are redirected (the ISO C99 printf
functions come to mind). These patches should not change the existing
behavior, though such symbols should be considered when mangling onto
the ldbl128 abi.
Builtin calls are something GCC will need to handled, and this is
brought up as part of PR 94630.
How many special cases for dlsym would there be today? I could see
three for ppc64le (ldbl == ibm, ldbl == dbl, ldbl == ieee128). I have
not seen this issue raised with ldbl == dbl redirects.
I would like to commit a patch to redirect dlsym/dlvsym in the event I
need to backport a solution, is that objectionable? Generating the
mangles from headers would be non-trivial, do you think this could be
done at build without additional built time dependencies?
More information about the Libc-alpha