mbox series

[v5,0/5] Allow ld.lld to link the MIPS VDSO

Message ID 20200428221419.2530697-1-natechancellor@gmail.com (mailing list archive)
Headers show
Series Allow ld.lld to link the MIPS VDSO | expand

Message

Nathan Chancellor April 28, 2020, 10:14 p.m. UTC 
Hi all,

This series allows ld.lld to properly and completely link the MIPS vDSO.

Patch 1 adds ld.lld support to Kconfig so that we can avoid certain
ld.bfd checks.

Patch 2 moves disabling of the VDSO to Kconfig. This allows us to avoid
a warning with LD=ld.lld during the clean phase, when we do not have
access to CONFIG_LD_IS_LLD.

Patch 3 prepares for the shift from $(CC) to $(LD) and is probably a
worthwhile change aside from this series because GCC 4.6 is the minimum
version allowed to build the kernel.

Patch 4 does the actual shift from $(CC) to $(LD) to link the VDSO.

Patch 5 allows LD=ld.lld to build the VDSO fully through Kconfig.

I have build tested 32r2_defconfig, 32r2el_defconfig, 64r2_defconfig,
and 64r2el_defconfig with GCC and 32r2el_defconfig and
malta_kvm_guest_defconfig with clang. There is a separate issue with the
64-bit configs (https://github.com/ClangBuiltLinux/linux/issues/884) and
ld.lld does not support the triple OUTPUT_FORMAT linker script macro so
32r2_defconfig errors out in a manner similar to GCC without patch 3:
https://github.com/llvm/llvm-project/blob/46a75436f811d0e6a2c76c669140a7e9471cd2a3/lld/ELF/ScriptParser.cpp#L430
TODO: File an LLVM bug upstream

Please let me know if there are any issues!

Cheers,
Nathan

Comments

Sedat Dilek April 29, 2020, 7:04 a.m. UTC | #1 
On Wed, Apr 29, 2020 at 12:14 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:

> Patch 1 adds ld.lld support to Kconfig so that we can avoid certain
> ld.bfd checks.
>

Is it possible to introduce and add LD_IS_BFD Kconfig for ld.bfd in this series?
Most people agreed on this name AFAICS.
What do people think?

- Sedat -
Nathan Chancellor April 30, 2020, 3:06 a.m. UTC | #2 
On Wed, Apr 29, 2020 at 09:04:42AM +0200, Sedat Dilek wrote:
> On Wed, Apr 29, 2020 at 12:14 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> 
> > Patch 1 adds ld.lld support to Kconfig so that we can avoid certain
> > ld.bfd checks.
> >
> 
> Is it possible to introduce and add LD_IS_BFD Kconfig for ld.bfd in this series?
> Most people agreed on this name AFAICS.
> What do people think?
> 
> - Sedat -

What is the use case for LD_IS_BFD right now? I am not sure I see a
reason to add a CONFIG value that won't see any immediate use.

Cheers,
Nathan
Thomas Bogendoerfer May 12, 2020, 8:05 a.m. UTC | #3 
On Tue, Apr 28, 2020 at 03:14:14PM -0700, Nathan Chancellor wrote:
> [..]
> Please let me know if there are any issues!

I found no issues in my tests. Is this the final state ? If yes, I'm
going to apply it to mips-next.

Thomas.
Nathan Chancellor May 12, 2020, 8:28 a.m. UTC | #4 
On Tue, May 12, 2020 at 10:05:09AM +0200, Thomas Bogendoerfer wrote:
> On Tue, Apr 28, 2020 at 03:14:14PM -0700, Nathan Chancellor wrote:
> > [..]
> > Please let me know if there are any issues!
> 
> I found no issues in my tests. Is this the final state ? If yes, I'm
> going to apply it to mips-next.
> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]

Maciej seemed to have some issue with the way I worded the commit
message of patch 4 but I have not heard anything back about my
suggestion and Fangrui commented that --eh-frame-hdr might not be
necessary but if everything works fine for you with this version, I
am not inclined to touch it.

If you feel this is good to go, I am happy to let it go in. Thanks for
accepting it!

Cheers,
Nathan
Thomas Bogendoerfer May 13, 2020, 11:18 a.m. UTC | #5 
On Tue, May 12, 2020 at 01:28:43AM -0700, Nathan Chancellor wrote:
> On Tue, May 12, 2020 at 10:05:09AM +0200, Thomas Bogendoerfer wrote:
> > On Tue, Apr 28, 2020 at 03:14:14PM -0700, Nathan Chancellor wrote:
> > > [..]
> > > Please let me know if there are any issues!
> > 
> > I found no issues in my tests. Is this the final state ? If yes, I'm
> > going to apply it to mips-next.
> > 
> > Thomas.
> > 
> > -- 
> > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> > good idea.                                                [ RFC1925, 2.3 ]
> 
> Maciej seemed to have some issue with the way I worded the commit
> message of patch 4 but I have not heard anything back about my
> suggestion and Fangrui commented that --eh-frame-hdr might not be
> necessary but if everything works fine for you with this version, I
> am not inclined to touch it.
> 
> If you feel this is good to go, I am happy to let it go in. Thanks for
> accepting it!

applied to mips-next.

Thomas.