[RFC PATCH 1/2] dlfcn: add long double redirect wrappers for dl*sym

Paul E Murphy murphyp@linux.ibm.com
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 mailing list