The gold linker has known issues of failing the build in random and
predictible ways. H.J. stated:
"Since building a workable kernel for different kernel configurations
isn't a requirement for gold, I don't recommend gold for kernel."
So instead of dealing with attempts to duct tape gold support without
understanding the root cause, fail the build when gold is detected.
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
---
scripts/Kconfig.include | 3 +++
1 file changed, 3 insertions(+)
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -35,5 +35,8 @@ ld-option = $(success,$(LD) -v $(1))
$(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
$(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
+# Fail if the linker is gold as it's not capable of linking the kernel proper
+$(error-if,$(success, command -v $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
+
# gcc version including patch level
gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
On Tue, Jul 16, 2019 at 02:47:56PM +0200, Thomas Gleixner wrote:
> The gold linker has known issues of failing the build in random and
> predictible ways. H.J. stated:
>
> "Since building a workable kernel for different kernel configurations
> isn't a requirement for gold, I don't recommend gold for kernel."
>
> So instead of dealing with attempts to duct tape gold support without
> understanding the root cause, fail the build when gold is detected.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
Right, life is too short to fight toolchains that aren't interested in
working.
Acked-by: Peter Zijlstra (Intel) <[email protected]>
> ---
> scripts/Kconfig.include | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -35,5 +35,8 @@ ld-option = $(success,$(LD) -v $(1))
> $(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
> $(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
>
> +# Fail if the linker is gold as it's not capable of linking the kernel proper
> +$(error-if,$(success, command -v $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
> +
> # gcc version including patch level
> gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
* Thomas Gleixner <[email protected]> wrote:
> The gold linker has known issues of failing the build in random and
> predictible ways. H.J. stated:
s/predictable/unpredictable?
Acked-by: Ingo Molnar <[email protected]>
Thanks,
Ingo
On Tue, 16 Jul 2019, Ingo Molnar wrote:
>
> * Thomas Gleixner <[email protected]> wrote:
>
> > The gold linker has known issues of failing the build in random and
> > predictible ways. H.J. stated:
>
> s/predictable/unpredictable?
No. It fails randomly, but also predictable. Enable X32 support on 64bit
and it fails the VDSO build. That's been the case for years.
Thanks,
tglx
On Tue, Jul 16, 2019 at 02:47:56PM +0200, Thomas Gleixner wrote:
> The gold linker has known issues of failing the build in random and
> predictible ways. H.J. stated:
>
> "Since building a workable kernel for different kernel configurations
> isn't a requirement for gold, I don't recommend gold for kernel."
>
> So instead of dealing with attempts to duct tape gold support without
> understanding the root cause, fail the build when gold is detected.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
> ---
> scripts/Kconfig.include | 3 +++
> 1 file changed, 3 insertions(+)
>
> --- a/scripts/Kconfig.include
> +++ b/scripts/Kconfig.include
> @@ -35,5 +35,8 @@ ld-option = $(success,$(LD) -v $(1))
> $(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
> $(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
>
> +# Fail if the linker is gold as it's not capable of linking the kernel proper
> +$(error-if,$(success, command -v $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
Why are there two '-v' flags here? The second one is ignored since
command -v just prints out the path of the binary that is being used,
which would work in most cases but not if gold is the default system
linker.
$ command -v ld.gold -v
/usr/bin/ld.gold
$ command -v ld.gold
/usr/bin/ld.gold
$ command ld.gold -v
GNU gold (GNU Binutils 2.32) 1.16
Thus, wouldn't it be better to just call $(LD) directly, like
CC_IS_GCC and CC_IS_CLANG in init/Kconfig?
$(success, $(LD) -v | grep -q gold)
Cheers,
Nathan
* Thomas Gleixner <[email protected]> wrote:
> On Tue, 16 Jul 2019, Ingo Molnar wrote:
>
> >
> > * Thomas Gleixner <[email protected]> wrote:
> >
> > > The gold linker has known issues of failing the build in random and
> > > predictible ways. H.J. stated:
> >
> > s/predictable/unpredictable?
>
> No. It fails randomly, but also predictable. Enable X32 support on 64bit
> and it fails the VDSO build. That's been the case for years.
Then please make this a bit more apparent, such as:
"The gold linker has known issues of failing the build in random
but also in more predictible ways."
or so?
Thanks,
Ingo
On Tue, Jul 16, 2019 at 11:13 AM Ingo Molnar <[email protected]> wrote:
>
> Then please make this a bit more apparent, such as:
>
> "The gold linker has known issues of failing the build in random
> but also in more predictible ways."
Maybe even mention a couple of particular known failure cases.
Just in case somebody decides to start up active gold development
again, and actually look at cases it fails at...
Linus
On Tue, Jul 16, 2019 at 08:13:24PM +0200, Ingo Molnar wrote:
>
> * Thomas Gleixner <[email protected]> wrote:
>
> > On Tue, 16 Jul 2019, Ingo Molnar wrote:
> >
> > >
> > > * Thomas Gleixner <[email protected]> wrote:
> > >
> > > > The gold linker has known issues of failing the build in random and
> > > > predictible ways. H.J. stated:
> > >
> > > s/predictable/unpredictable?
> >
> > No. It fails randomly, but also predictable. Enable X32 support on 64bit
> > and it fails the VDSO build. That's been the case for years.
>
> Then please make this a bit more apparent, such as:
>
> "The gold linker has known issues of failing the build in random
> but also in more predictible ways."
<bikeshedding>
How about:
The gold linker has known issues of failing for certain configurations.
</bikeshedding>
- Ted
On Tue, 16 Jul 2019, Nathan Chancellor wrote:
> On Tue, Jul 16, 2019 at 02:47:56PM +0200, Thomas Gleixner wrote:
> > The gold linker has known issues of failing the build in random and
> > predictible ways. H.J. stated:
> >
> > "Since building a workable kernel for different kernel configurations
> > isn't a requirement for gold, I don't recommend gold for kernel."
> >
> > So instead of dealing with attempts to duct tape gold support without
> > understanding the root cause, fail the build when gold is detected.
> >
> > Signed-off-by: Thomas Gleixner <[email protected]>
> > Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
> > ---
> > scripts/Kconfig.include | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > --- a/scripts/Kconfig.include
> > +++ b/scripts/Kconfig.include
> > @@ -35,5 +35,8 @@ ld-option = $(success,$(LD) -v $(1))
> > $(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
> > $(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
> >
> > +# Fail if the linker is gold as it's not capable of linking the kernel proper
> > +$(error-if,$(success, command -v $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
>
> Why are there two '-v' flags here? The second one is ignored since
> command -v just prints out the path of the binary that is being used,
> which would work in most cases but not if gold is the default system
> linker.
>
> $ command -v ld.gold -v
> /usr/bin/ld.gold
>
> $ command -v ld.gold
> /usr/bin/ld.gold
>
> $ command ld.gold -v
> GNU gold (GNU Binutils 2.32) 1.16
>
> Thus, wouldn't it be better to just call $(LD) directly, like
> CC_IS_GCC and CC_IS_CLANG in init/Kconfig?
>
> $(success, $(LD) -v | grep -q gold)
Right you are. Copy and paste without brain ....
The gold linker has known issues of failing the build both in random and in
predictible ways:
- The x86/X32 VDSO build fails with:
arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
error: relocation overflow: reference to 'hvclock_page'
That's a known issue for years and the usual workaround is to disable
CONFIG_X86_32
- A recent build failure is caused by turning a relocation into an
absolute one for unknown reasons. See link below.
- There are a couple of gold workarounds applied already, but reports
about broken builds with ld.gold keep coming in on a regular base and in
most cases the root cause is unclear.
In context of the most recent fail H.J. stated:
"Since building a workable kernel for different kernel configurations
isn't a requirement for gold, I don't recommend gold for kernel."
So instead of dealing with attempts to duct tape gold support without
understanding the root cause and without support from the gold folks, fail
the build when gold is detected.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
---
V2: Better changelog
Use the proper check as pointed out by Nathan
---
scripts/Kconfig.include | 3 +++
1 file changed, 3 insertions(+)
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -35,5 +35,8 @@ ld-option = $(success,$(LD) -v $(1))
$(error-if,$(failure,command -v $(CC)),compiler '$(CC)' not found)
$(error-if,$(failure,command -v $(LD)),linker '$(LD)' not found)
+# Fail if the linker is gold as it's not capable of linking the kernel proper
+$(error-if,$(success, $(LD) -v | grep -q gold), gold linker '$(LD)' not supported)
+
# gcc version including patch level
gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
On Tue, Jul 16, 2019 at 09:47:27PM +0200, Thomas Gleixner wrote:
> The gold linker has known issues of failing the build both in random and in
> predictible ways:
>
> - The x86/X32 VDSO build fails with:
>
> arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
> error: relocation overflow: reference to 'hvclock_page'
>
> That's a known issue for years and the usual workaround is to disable
> CONFIG_X86_32
>
> - A recent build failure is caused by turning a relocation into an
> absolute one for unknown reasons. See link below.
>
> - There are a couple of gold workarounds applied already, but reports
> about broken builds with ld.gold keep coming in on a regular base and in
> most cases the root cause is unclear.
>
> In context of the most recent fail H.J. stated:
>
> "Since building a workable kernel for different kernel configurations
> isn't a requirement for gold, I don't recommend gold for kernel."
>
> So instead of dealing with attempts to duct tape gold support without
> understanding the root cause and without support from the gold folks, fail
> the build when gold is detected.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Acked-by: Peter Zijlstra (Intel) <[email protected]>
> Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
Based on the crude little testing script I wrote below:
Reviewed-by: Nathan Chancellor <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
$ cat test.sh
#!/bin/bash
# ld.bfd (expected to pass)
make distclean defconfig || exit ${?}
# ld.gold explicitly (expected to fail)
make LD=ld.gold distclean defconfig && exit ${?}
# ld.gold as if it were the system linker (expected to fail)
ln -fs /usr/bin/ld.gold ld
PATH=${PWD}:${PATH} make distclean defconfig && exit ${?}
# ld.lld (expected to pass)
make LD=ld.lld distclean defconfig || exit ${?}
On Tue, 16 Jul 2019 at 21:00, Nathan Chancellor
<[email protected]> wrote:
>
> On Tue, Jul 16, 2019 at 09:47:27PM +0200, Thomas Gleixner wrote:
> > The gold linker has known issues of failing the build both in random and in
> > predictible ways:
> >
> > - The x86/X32 VDSO build fails with:
> >
> > arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
> > error: relocation overflow: reference to 'hvclock_page'
> >
> > That's a known issue for years and the usual workaround is to disable
> > CONFIG_X86_32
> >
> > - A recent build failure is caused by turning a relocation into an
> > absolute one for unknown reasons. See link below.
> >
> > - There are a couple of gold workarounds applied already, but reports
> > about broken builds with ld.gold keep coming in on a regular base and in
> > most cases the root cause is unclear.
> >
> > In context of the most recent fail H.J. stated:
> >
> > "Since building a workable kernel for different kernel configurations
> > isn't a requirement for gold, I don't recommend gold for kernel."
> >
> > So instead of dealing with attempts to duct tape gold support without
> > understanding the root cause and without support from the gold folks, fail
> > the build when gold is detected.
> >
> > Signed-off-by: Thomas Gleixner <[email protected]>
> > Acked-by: Peter Zijlstra (Intel) <[email protected]>
> > Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
>
> Based on the crude little testing script I wrote below:
>
> Reviewed-by: Nathan Chancellor <[email protected]>
> Tested-by: Nathan Chancellor <[email protected]>
>
> $ cat test.sh
> #!/bin/bash
>
> # ld.bfd (expected to pass)
> make distclean defconfig || exit ${?}
>
> # ld.gold explicitly (expected to fail)
> make LD=ld.gold distclean defconfig && exit ${?}
>
> # ld.gold as if it were the system linker (expected to fail)
> ln -fs /usr/bin/ld.gold ld
> PATH=${PWD}:${PATH} make distclean defconfig && exit ${?}
>
> # ld.lld (expected to pass)
> make LD=ld.lld distclean defconfig || exit ${?}
Hi
Would it be possible to force ld.bfd with -fuse-ld=bfd when gold is detected?
Are there gold bug reports for any of the issues that have been seen
with gold? It's been my default system linker for years and I've had
very few issues with it and it's a big improvement when linking with
LTO
Cheers
Mike
Mike,
On Tue, 16 Jul 2019, Mike Lothian wrote:
> On Tue, 16 Jul 2019 at 21:00, Nathan Chancellor wrote
>
> Would it be possible to force ld.bfd with -fuse-ld=bfd when gold is detected?
It's probably possible but way beyond my kbuild foo.
Adding LD=ld.bfd to the make invocation is the trivial workaround.
> Are there gold bug reports for any of the issues that have been seen
> with gold?
Yes. Some got resolved, some not.
> It's been my default system linker for years and I've had very few issues
> with it and it's a big improvement when linking with LTO
I understand, but the fact that you need to turn off config options in
order to build a kernel and the clear statement that it's not recommended
makes it truly unsuitable and unmaintainable for us.
If the gold people are interested to link a kernel and resolve all issues,
this surely can be revisited. We work with tooling folks and we try to
accomodate different tools, see the ongoing efforts for clang, but that
requires commitment from the tooling side.
Thanks,
tglx
On Wed, Jul 17, 2019 at 12:25:14AM +0200, Thomas Gleixner wrote:
> > It's been my default system linker for years and I've had very few issues
> > with it and it's a big improvement when linking with LTO
>
> I understand, but the fact that you need to turn off config options in
> order to build a kernel and the clear statement that it's not recommended
> makes it truly unsuitable and unmaintainable for us.
Or if you work for a cloud company who is willing to make the gold
linker work for your specific use case and configuration (and ideally,
have gold toolchain experts on staff who will work with you), then it
might be OK, but just for that particular use case. (Just as Android
kernels worked with Clang when Clang was still miscompiling kernel on
different architectures and configurations.) In those cases, you can
just carry a patch to force the gold linker to work.
The point though is the teams that were using alternative,
not-always-reliable toolchains, were big boys and girls, and they
weren't asking the upstream kernel devs for support. And they only
cared about a few specific configurations, and not something that
would work for all or even most configurations and hardware platforms.
- Ted
On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner <[email protected]> wrote:
>
> The gold linker has known issues of failing the build both in random and in
> predictible ways:
>
> - The x86/X32 VDSO build fails with:
>
> arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
> error: relocation overflow: reference to 'hvclock_page'
>
> That's a known issue for years and the usual workaround is to disable
> CONFIG_X86_32
>
> - A recent build failure is caused by turning a relocation into an
> absolute one for unknown reasons. See link below.
>
> - There are a couple of gold workarounds applied already, but reports
> about broken builds with ld.gold keep coming in on a regular base and in
> most cases the root cause is unclear.
>
> In context of the most recent fail H.J. stated:
>
> "Since building a workable kernel for different kernel configurations
> isn't a requirement for gold, I don't recommend gold for kernel."
>
> So instead of dealing with attempts to duct tape gold support without
> understanding the root cause and without support from the gold folks, fail
> the build when gold is detected.
>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Acked-by: Peter Zijlstra (Intel) <[email protected]>
> Link: https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com
> ---
The code looks OK in the build system point of view.
Please let me confirm this, just in case:
For now, we give up all architectures, not only x86, right?
I have not not heard much from other arch maintainers.
--
Best Regards
Masahiro Yamada
On Wed, 17 Jul 2019, Masahiro Yamada wrote:
> On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner <[email protected]> wrote:
> > So instead of dealing with attempts to duct tape gold support without
> > understanding the root cause and without support from the gold folks, fail
> > the build when gold is detected.
> >
>
> The code looks OK in the build system point of view.
>
> Please let me confirm this, just in case:
> For now, we give up all architectures, not only x86, right?
Well, that's the logical consequence of a statement which says: don't use
gold for the kernel.
> I have not not heard much from other arch maintainers.
Cc'ed linux-arch for that matter.
Thanks,
tglx
On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner <[email protected]> wrote:
>
> On Wed, 17 Jul 2019, Masahiro Yamada wrote:
> > On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner <[email protected]> wrote:
> > > So instead of dealing with attempts to duct tape gold support without
> > > understanding the root cause and without support from the gold folks, fail
> > > the build when gold is detected.
> > >
> >
> > The code looks OK in the build system point of view.
> >
> > Please let me confirm this, just in case:
> > For now, we give up all architectures, not only x86, right?
>
> Well, that's the logical consequence of a statement which says: don't use
> gold for the kernel.
>
> > I have not not heard much from other arch maintainers.
>
> Cc'ed linux-arch for that matter.
>
> Thanks,
>
> tglx
Hi
I've done a bit more digging, I had a second machine that was building
Linus's tree just fine with ld.gold
I tried forcing ld.bfd on the problem machine and got this:
ld.bfd: arch/x86/boot/compressed/head_64.o: warning: relocation in
read-only section `.head.text'
ld.bfd: warning: creating a DT_TEXTREL in object
I had a look at the differences in the kernel configs and noticed this:
CONFIG_RANDOMIZE_BASE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_DYNAMIC_MEMORY_LAYOUT=y
CONFIG_RANDOMIZE_MEMORY=y
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0x0
Unsetting CONFIG_RANDOMIZE_BASE=y gets things working for me with ld.gold again
In light of this - can we drop this patch?
Cheers
Mike
On Sat, 20 Jul 2019, Mike Lothian wrote:
> On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner <[email protected]> wrote:
> I've done a bit more digging, I had a second machine that was building
> Linus's tree just fine with ld.gold
>
> I tried forcing ld.bfd on the problem machine and got this:
>
> ld.bfd: arch/x86/boot/compressed/head_64.o: warning: relocation in
> read-only section `.head.text'
> ld.bfd: warning: creating a DT_TEXTREL in object
>
> I had a look at the differences in the kernel configs and noticed this:
>
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_X86_NEED_RELOCS=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_DYNAMIC_MEMORY_LAYOUT=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0x0
>
> Unsetting CONFIG_RANDOMIZE_BASE=y gets things working for me with ld.gold again
Can you please provide the full config? I have the above set here and it
builds just fine.
> In light of this - can we drop this patch?
No. I'm not going to deal with unsupported tools.
Thanks,
tglx
On Sat, 20 Jul 2019 at 10:34, Thomas Gleixner <[email protected]> wrote:
>
> On Sat, 20 Jul 2019, Mike Lothian wrote:
> > On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner <[email protected]> wrote:
> > I've done a bit more digging, I had a second machine that was building
> > Linus's tree just fine with ld.gold
> >
> > I tried forcing ld.bfd on the problem machine and got this:
> >
> > ld.bfd: arch/x86/boot/compressed/head_64.o: warning: relocation in
> > read-only section `.head.text'
> > ld.bfd: warning: creating a DT_TEXTREL in object
> >
> > I had a look at the differences in the kernel configs and noticed this:
> >
> > CONFIG_RANDOMIZE_BASE=y
> > CONFIG_X86_NEED_RELOCS=y
> > CONFIG_PHYSICAL_ALIGN=0x1000000
> > CONFIG_DYNAMIC_MEMORY_LAYOUT=y
> > CONFIG_RANDOMIZE_MEMORY=y
> > CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0x0
> >
> > Unsetting CONFIG_RANDOMIZE_BASE=y gets things working for me with ld.gold again
>
> Can you please provide the full config? I have the above set here and it
> builds just fine.
>
> > In light of this - can we drop this patch?
>
> No. I'm not going to deal with unsupported tools.
>
> Thanks,
>
> tglx
Hi
Here is my config
https://github.com/FireBurn/KernelStuff/blob/9b7e96581598d50b266f9df258e7de764949147a/dot_config_tip
Regards
Mike
On Sat, 20 Jul 2019, Mike Lothian wrote:
> Here is my config
>
> https://github.com/FireBurn/KernelStuff/blob/9b7e96581598d50b266f9df258e7de764949147a/dot_config_tip
>
Builds perfectly fine.
On Sat, 20 Jul 2019 at 11:54, Thomas Gleixner <[email protected]> wrote:
>
> On Sat, 20 Jul 2019, Mike Lothian wrote:
> > Here is my config
> >
> > https://github.com/FireBurn/KernelStuff/blob/9b7e96581598d50b266f9df258e7de764949147a/dot_config_tip
> >
>
> Builds perfectly fine.
Sorry top posted from my phone
Are you using gold? And which versions of GCC & binutils are you using?
On Sat, Jul 20, 2019 at 6:12 PM Mike Lothian <[email protected]> wrote:
>
> On Wed, 17 Jul 2019 at 08:57, Thomas Gleixner <[email protected]> wrote:
> >
> > On Wed, 17 Jul 2019, Masahiro Yamada wrote:
> > > On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner <[email protected]> wrote:
> > > > So instead of dealing with attempts to duct tape gold support without
> > > > understanding the root cause and without support from the gold folks, fail
> > > > the build when gold is detected.
> > > >
> > >
> > > The code looks OK in the build system point of view.
> > >
> > > Please let me confirm this, just in case:
> > > For now, we give up all architectures, not only x86, right?
> >
> > Well, that's the logical consequence of a statement which says: don't use
> > gold for the kernel.
> >
> > > I have not not heard much from other arch maintainers.
> >
> > Cc'ed linux-arch for that matter.
> >
> > Thanks,
> >
> > tglx
>
> Hi
>
> I've done a bit more digging, I had a second machine that was building
> Linus's tree just fine with ld.gold
>
> I tried forcing ld.bfd on the problem machine and got this:
>
> ld.bfd: arch/x86/boot/compressed/head_64.o: warning: relocation in
> read-only section `.head.text'
> ld.bfd: warning: creating a DT_TEXTREL in object
>
> I had a look at the differences in the kernel configs and noticed this:
>
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_X86_NEED_RELOCS=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_DYNAMIC_MEMORY_LAYOUT=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0x0
>
> Unsetting CONFIG_RANDOMIZE_BASE=y gets things working for me with ld.gold again
Right.
I was able to build with ld.gold
So, we can use gold, depending on the kernel configuration.
> In light of this - can we drop this patch?
--
Best Regards
Masahiro Yamada
On Tue, 23 Jul 2019, Masahiro Yamada wrote:
> Right.
> I was able to build with ld.gold
>
> So, we can use gold, depending on the kernel configuration.
That's exactly the problem. It breaks with random kernel configurations
which is not acceptable except for people who know what they are doing.
I'm tired of dealing with half baken fixes and 'regression' reports. Either
there is an effort to fix the issues with gold like the clang people fix
their issues or it needs to be disabled. We have a clear statement that
gold developers have other priorities.
Thanks,
tglx
On Tue, 23 Jul 2019, Thomas Gleixner wrote:
> On Tue, 23 Jul 2019, Masahiro Yamada wrote:
> > Right.
> > I was able to build with ld.gold
> >
> > So, we can use gold, depending on the kernel configuration.
>
> That's exactly the problem. It breaks with random kernel configurations
> which is not acceptable except for people who know what they are doing.
>
> I'm tired of dealing with half baken fixes and 'regression' reports. Either
> there is an effort to fix the issues with gold like the clang people fix
> their issues or it needs to be disabled. We have a clear statement that
> gold developers have other priorities.
That said, I'm perfectly happy to move this to x86 and leave it alone for
other architectures, but it does not make sense to me.
If the gold fans care enough, then we can add something like
CONFIG_I_WANT_TO_USE_GOLD_AND_DEAL_WITH_THE_FALLOUT_MYSELF.
Thanks,
tglx
On Tue, Jul 23, 2019 at 5:17 PM Thomas Gleixner <[email protected]> wrote:
>
> On Tue, 23 Jul 2019, Thomas Gleixner wrote:
> > On Tue, 23 Jul 2019, Masahiro Yamada wrote:
> > > Right.
> > > I was able to build with ld.gold
> > >
> > > So, we can use gold, depending on the kernel configuration.
> >
> > That's exactly the problem. It breaks with random kernel configurations
> > which is not acceptable except for people who know what they are doing.
> >
> > I'm tired of dealing with half baken fixes and 'regression' reports. Either
> > there is an effort to fix the issues with gold like the clang people fix
> > their issues or it needs to be disabled. We have a clear statement that
> > gold developers have other priorities.
>
> That said, I'm perfectly happy to move this to x86 and leave it alone for
> other architectures, but it does not make sense to me.
I did not see opposition from other arch maintainers.
> If the gold fans care enough, then we can add something like
> CONFIG_I_WANT_TO_USE_GOLD_AND_DEAL_WITH_THE_FALLOUT_MYSELF.
Let's apply this and see.
If somebody really wants to use gold by his risk,
I will consider such a config option.
Applied to linux-kbuild.
Thanks.
--
Best Regards
Masahiro Yamada
Hi all!
On 16/07/2019 17:59, Thomas Gleixner wrote:
[...]
> No. It fails randomly, but also predictable. Enable X32 support on 64bit
> and it fails the VDSO build. That's been the case for years.
FWIW "GNU gold (GNU Binutils for Ubuntu 2.30) 1.15" segfaults for
userspace x32 binaries now and then (in unpredictable ways) too.
MfG,
Bernd--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds