Hello LLVM community,
I am evaluating profitability of using the LLVM lld for linking our
projects.
As a test, I tried to build the latest Boost with clang / lld on X86_64
Ubuntu and faced a problem at the very first step of doing this. One of
the Boost's auxiliary tools refers to the "environ" variable to
access
the environment variables. "environ" is defined in glibc and is
actually
a weak alias for the "__environ" variable. Here is a fragment of
posix/environ.c:
char **__environ = NULL; // var pointing to env vars array
weak_alias (__environ, environ) // and two weak aliases to it
weak_alias (__environ, _environ)
When linking a program that accesses "environ" with binutils' ld,
the
symbol is correctly marked as a weak object:
> nm a.out | grep environ
0000000000601040 B __environ@@GLIBC_2.2.5
0000000000601040 *V *environ@@GLIBC_2.2.5
LLVM lld marks it as uninitialized data from the BSS section:
0000000000401168 *B* environ
Readelf also shows different symbols (readelf -s a.out | grep environ):
- ld:
4: 0000000000601040 8 OBJECT WEAK DEFAULT 25
_environ at GLIBC_2.2.5 (2)
5: 0000000000601040 8 OBJECT WEAK DEFAULT 25
environ at GLIBC_2.2.5 (2) <- environ is a weak object
6: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25
__environ at GLIBC_2.2.5 (2) <- __environ itself is present as a global
54: 0000000000601040 8 OBJECT WEAK DEFAULT 25
environ@@GLIBC_2.2.5
63: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25
__environ@@GLIBC_2.2.5
- lld
1: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22
environ <- no __environ reference. Environ is a global, not weak
8: 0000000000000000 8 OBJECT GLOBAL DEFAULT UND environ
37: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22 environ
This leads to "environ" being nil when running the lld-linked binary.
Is it a known problem?
What is the fullness of ELF/Linux support?
Where can I find the features list that are expected to work and what
work is still in progress?
Thank you!
Kind regards,
Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140912/b73e0355/attachment.html>
On 12 September 2014 10:35, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote:> Is it a known problem? > What is the fullness of ELF/Linux support?AFAIK, ELF/Linux support in lld is patchy, but work is being done to fix that.> Where can I find the features list that are expected to work and what work > is still in progress?Good question, one that I also want to know. But my guess is that there isn't any. My feeling is that people are waking up to the fact that lld is a very promising linker, one that we should all try to make production quality and use by default (just like we did with the integrated assembler), but we're still at the early days. I have plans to make that so, at least for ARM/Linux and AArch64/Linux, but at the moment, I have no resources to work on that. This may change in the near future. cheers, --renato
Hi Oleg, There may be multiple issues on handling weak symbols, I will try to fix this. Shankar Easwaran On 9/12/2014 4:35 AM, Oleg Ranevskyy wrote:> Hello LLVM community, > > I am evaluating profitability of using the LLVM lld for linking our > projects. > > As a test, I tried to build the latest Boost with clang / lld on > X86_64 Ubuntu and faced a problem at the very first step of doing > this. One of the Boost's auxiliary tools refers to the "environ" > variable to access the environment variables. "environ" is defined in > glibc and is actually a weak alias for the "__environ" variable. Here > is a fragment of posix/environ.c: > > char **__environ = NULL; // var pointing to env vars array > weak_alias (__environ, environ) // and two weak aliases to it > weak_alias (__environ, _environ) > > When linking a program that accesses "environ" with binutils' ld, the > symbol is correctly marked as a weak object: > > nm a.out | grep environ > 0000000000601040 B __environ@@GLIBC_2.2.5 > 0000000000601040 *V *environ@@GLIBC_2.2.5 > > LLVM lld marks it as uninitialized data from the BSS section: > 0000000000401168 *B* environ > > Readelf also shows different symbols (readelf -s a.out | grep environ): > - ld: > 4: 0000000000601040 8 OBJECT WEAK DEFAULT 25 > _environ at GLIBC_2.2.5 (2) > 5: 0000000000601040 8 OBJECT WEAK DEFAULT 25 > environ at GLIBC_2.2.5 (2) <- environ is a weak object > 6: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25 > __environ at GLIBC_2.2.5 (2) <- __environ itself is present as a global > 54: 0000000000601040 8 OBJECT WEAK DEFAULT 25 > environ@@GLIBC_2.2.5 > 63: 0000000000601040 8 OBJECT GLOBAL DEFAULT 25 > __environ@@GLIBC_2.2.5 > > - lld > 1: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22 > environ <- no __environ reference. Environ is a global, not weak > 8: 0000000000000000 8 OBJECT GLOBAL DEFAULT UND environ > 37: 0000000000401168 8 OBJECT GLOBAL DEFAULT 22 environ > > This leads to "environ" being nil when running the lld-linked binary. > > Is it a known problem? > What is the fullness of ELF/Linux support? > Where can I find the features list that are expected to work and what > work is still in progress? > > Thank you! > > Kind regards, > Oleg > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140912/44e2cff3/attachment.html>