[LLVMdev] [RFC] Linkage of user-supplied library functions in LTO

[Krzysztof Parzyszek]

On 3/8/2014 10:59 AM, Duncan P. N. Exon Smith wrote:
> +nick and rafael, who seem to a lot about linkage.
>
> I made the following claim on llmv-commits [1]:
>
> On 2014 Mar 3, at 15:01, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>
>> Giving these functions internal linkage allows them to be dead-stripped.
>
> Is that even correct?

If by "linker" you mean things like /bin/ld, then linkers can 
garbage-collect sections that don't contain any referenced symbols, not 
the symbols themselves. I believe it doesn't matter if the symbols in 
sections are internal or external---that only matters for symbol resolution.


> The current state of user-supplied library functions in LTO is that we
> internalize library functions, add them to llvm.compiler.used so that
> optimizations don’t modify them, and then optimizations incorrectly
> modify them.  LLVM *really* doesn't expect library functions to have
> local linkage.

I've read the original thread (the 3 emails), and I'm still not sure 
what the purpose of internalization is in the context of user-provided 
library functions. If the output of LTO is one giant object file, it 
could make some sense (since the assembler could potentially do the 
"symbol resolution"). Otherwise the problem is in telling the "ld" which 
definition of "printf" it needs to pick up, or asking the user not to 
link the program with libc (a bit of a questionable request).

How are optimizations "incorrectly modifying" (user-provided) library 
functions?


-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation