[LLVMdev] [RFC] Linkage of user-supplied library functions in LTO
Rafael EspĂndola
rafael.espindola at gmail.com
Mon Mar 10 13:01:08 PDT 2014
> I see. Thanks for the explanation.
>
>
> How about this: resolve symbols during LTO and detect which ones are used in
> the program, and which are not? It would probably require a lot more work
> in the LTO framework, but it has the benefit that we no longer need any
> "preserve" list merely to allow it to link, or "internalization". The only
> exception would be export lists for shared objects, but it would be a lot
> easier for the user to provide that, than to list all the functions
> referenced from other objects/libraries.
>
> To help with user-provided library functions we could develop a way for the
> user to specify "resolution preference", i.e. if "printf" is not explicitly
> defined, pick it up from /usr/lib/libc.a, otherwise ignore the definition
> from libc.a.
> This would only work for linking non-shared objects though. If the user
> wants to get the rest of the functions from libc, the replaced ones would
> need to be internally renamed to avoid conflicts with those in libc (the
> system linker could otherwise complain).
During LTO time we don't know exactly which functions will be used. If
memcpy is used or not depends on which backend we are using for
example. The only reliable way would be iterate codegen, making not at
each step which new undefined references shows up, which is an
overkill.
The current strategy of just knowing which symbols llvm *might* use
seems appropriate, we just to fix llvm to always respect it.
Cheers,
Rafael
More information about the llvm-dev
mailing list