linux-kernel - Re: build failure caused by RUNTIME

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240802221014.GA20135@redhat.com>
Date: Sat, 3 Aug 2024 00:10:14 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: build failure caused by RUNTIME_CONST()

On 08/02, Linus Torvalds wrote:
>
> > The patch below seems to fix the problem, but I didn't find any report on lkml,
> > so perhaps I am the only one which hits this problem? And perhaps this is because
> > my gcc 5.3.1 is quite old?
>
> It's not your gcc. It must be your linker that is old and decrepit.

Ah, sorry. Of course I understood that this must ba a linker issue, sorry for
confusion!

	$ ld -v
	GNU ld version 2.25-17.fc23

> > OTOH, I know nothing about lds magic, so I fail to understand where these
> > __start/stop_runtime_xxx can come from without something like the change below...
>
> So it comes from this:
>
>     https://sourceware.org/binutils/docs/ld/Input-Section-Example.html
>
> and in there you will find
>
>    "If an output section’s name is the same as the input section’s name
>     and is representable as a C identifier, then the linker will
>     automatically see PROVIDE two symbols: __start_SECNAME and
>     __stop_SECNAME, where SECNAME is the name of the section. These
>     indicate the start address and end address of the output section
>     respectively"

Thanks!

> but apparently your linker doesn't do that.

apparently yes,

> I guess we'll have to go with doing this manually as in your patch,

OK... so if you think it makes sense to support the old toolchains,
perhaps you can commit the "proper" patch?

I can try to polish my hack, but as I said I don't understand this magic,
and I can only test the build on x86.

Oleg.