diff mbox series

[v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds

Message ID 20190329064453.12761-1-joel@jms.id.au (mailing list archive)
State Changes Requested
Headers show
Series [v2] powerpc/vmlinux.lds: Drop binutils < 2.18 workarounds | expand

Checks

Context Check Description
snowpatch_ozlabs/apply_patch success Successfully applied on branch next (9e98c678c2d6ae3a17cb2de55d17f69dddaa231b)
snowpatch_ozlabs/build-ppc64le success Build succeeded
snowpatch_ozlabs/build-ppc64be success Build succeeded
snowpatch_ozlabs/build-ppc64e success Build succeeded
snowpatch_ozlabs/build-pmac32 success Build succeeded
snowpatch_ozlabs/checkpatch fail total: 1 errors, 1 warnings, 0 checks, 37 lines checked

Commit Message

Joel Stanley March 29, 2019, 6:44 a.m. UTC
Segher added some workarounds for binutils < 2.18 and GCC < 4.2. We
now set GCC 4.6 and binutils 2.20 as the minimum, so the workarounds
can be dropped.

This is mostly a revert of c69cccc95fe4 ("powerpc: Fix build bug with
binutils < 2.18 and GCC < 4.2"), except we keep the kernel PHDRS
statement as ppc64_defconfig would fail to link without it:

 powerpc64-linux-ld: .tmp_vmlinux1: Not enough room for program headers, try linking with -N
 powerpc64-linux-ld: final link failed: Bad value

See https://lore.kernel.org/linuxppc-dev/20190321003253.22100-1-joel@jms.id.au/
for the discussion.

Signed-off-by: Joel Stanley <joel@jms.id.au>
---
v2: Fix ppc64_defconfig by keeping kernel PHDRS

Segher, Christophe, I did my best but to summarise your conversation.
Please suggest corrections or additions to the commit message if you
have any.

---
 arch/powerpc/kernel/vmlinux.lds.S | 25 +------------------------
 1 file changed, 1 insertion(+), 24 deletions(-)

Comments

Segher Boessenkool March 29, 2019, 9:53 a.m. UTC | #1
Hi!

On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> -	NOTES :kernel :notes
> +	NOTES

I think this still need to be

	NOTES :kernel

or the linker will complain.  Did you try to build ppc64_defconfig?

(And I do not know if there are any tools that expect the notes in a phdr,
or even specifically the second phdr).


Segher
Joel Stanley April 4, 2019, 12:17 p.m. UTC | #2
On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > -     NOTES :kernel :notes
> > +     NOTES
>
> I think this still need to be
>
>         NOTES :kernel
>
> or the linker will complain.  Did you try to build ppc64_defconfig?

Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
leaving in/removing the :kernel annotation in a bunch of places and as
long as I had it in the first spot, the kernel linked.

Shall I respin with this added?

> (And I do not know if there are any tools that expect the notes in a phdr,
> or even specifically the second phdr).
>
>
> Segher
Segher Boessenkool April 4, 2019, 2:53 p.m. UTC | #3
Hi Joel,

On Thu, Apr 04, 2019 at 12:17:40PM +0000, Joel Stanley wrote:
> On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
> > > -     NOTES :kernel :notes
> > > +     NOTES
> >
> > I think this still need to be
> >
> >         NOTES :kernel
> >
> > or the linker will complain.  Did you try to build ppc64_defconfig?
> 
> Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
> leaving in/removing the :kernel annotation in a bunch of places and as
> long as I had it in the first spot, the kernel linked.
> 
> Shall I respin with this added?

Yes please, if only so we are testing the exact same thing :-)

There may be a binutils version difference here.

> > (And I do not know if there are any tools that expect the notes in a phdr,
> > or even specifically the second phdr).

^^^ This question remains?


Segher
Christophe Leroy April 4, 2019, 2:58 p.m. UTC | #4
Le 04/04/2019 à 16:53, Segher Boessenkool a écrit :
> Hi Joel,
> 
> On Thu, Apr 04, 2019 at 12:17:40PM +0000, Joel Stanley wrote:
>> On Fri, 29 Mar 2019 at 09:53, Segher Boessenkool
>> <segher@kernel.crashing.org> wrote:
>>> On Fri, Mar 29, 2019 at 05:14:53PM +1030, Joel Stanley wrote:
>>>> -     NOTES :kernel :notes
>>>> +     NOTES
>>>
>>> I think this still need to be
>>>
>>>          NOTES :kernel
>>>
>>> or the linker will complain.  Did you try to build ppc64_defconfig?
>>
>> Yeah, I did build (and boot, in qemu) the ppc64_defconfig. I tried
>> leaving in/removing the :kernel annotation in a bunch of places and as
>> long as I had it in the first spot, the kernel linked.
>>
>> Shall I respin with this added?
> 
> Yes please, if only so we are testing the exact same thing :-)
> 
> There may be a binutils version difference here.
> 
>>> (And I do not know if there are any tools that expect the notes in a phdr,
>>> or even specifically the second phdr).
> 
> ^^^ This question remains?

A few days ago while I was investigating 
https://github.com/linuxppc/issues/issues/208 , I had the feeling that 
QEMU expects some sort of NOTES section.

I didn't investigate further though.

Christophe
diff mbox series

Patch

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 060a1acd7c6d..9ddc7c0dc672 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -19,21 +19,6 @@  ENTRY(_stext)
 
 PHDRS {
 	kernel PT_LOAD FLAGS(7); /* RWX */
-	notes PT_NOTE FLAGS(0);
-	dummy PT_NOTE FLAGS(0);
-
-	/* binutils < 2.18 has a bug that makes it misbehave when taking an
-	   ELF file with all segments at load address 0 as input.  This
-	   happens when running "strip" on vmlinux, because of the AT() magic
-	   in this linker script.  People using GCC >= 4.2 won't run into
-	   this problem, because the "build-id" support will put some data
-	   into the "notes" segment (at a non-zero load address).
-
-	   To work around this, we force some data into both the "dummy"
-	   segment and the kernel segment, so the dummy segment will get a
-	   non-zero load address.  It's not enough to always create the
-	   "notes" segment, since if nothing gets assigned to it, its load
-	   address will be zero.  */
 }
 
 #ifdef CONFIG_PPC64
@@ -177,15 +162,7 @@  SECTIONS
 #endif
 	EXCEPTION_TABLE(0)
 
-	NOTES :kernel :notes
-
-	/* The dummy segment contents for the bug workaround mentioned above
-	   near PHDRS.  */
-	.dummy : AT(ADDR(.dummy) - LOAD_OFFSET) {
-		LONG(0)
-		LONG(0)
-		LONG(0)
-	} :kernel :dummy
+	NOTES
 
 /*
  * Init sections discarded at runtime