On Tue, Jan 03, 2023 at 11:58:48AM +0100, Ard Biesheuvel wrote: > On Tue, 3 Jan 2023 at 03:13, Linus Torvalds > wrote: > > > > On Mon, Jan 2, 2023 at 5:45 PM Guenter Roeck wrote: > > > > > > ... and reverting commit 99cb0d917ff indeed fixes the problem. > > > > Hmm. My gut feel is that this just exposes some bug in binutils. > > > > That said, maybe that commit should not have added its own /DISCARDS/ > > thing, and instead just added that "*(.note.GNU-stack)" to the general > > /DISCARDS/ thing that is defined by the > > > > #define DISCARDS .. > > > > a little bit later, so that we only end up with one single DISCARD > > list. Something like this (broken patch on purpose): > > > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -897,5 +897,4 @@ > > */ > > #define NOTES \ > > - /DISCARD/ : { *(.note.GNU-stack) } \ > > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ > > BOUNDED_SECTION_BY(.note.*, _notes) \ > > @@ -1016,4 +1015,5 @@ > > #define DISCARDS \ > > /DISCARD/ : { \ > > + *(.note.GNU-stack) \ > > EXIT_DISCARDS \ > > EXIT_CALL \ > > > > But maybe that DISCARDS macrop ends up being used too late? > > > > Masahiro's v1 did something like this, and it caused an issue on > RISC-V, which is why we ended up with this approach instead. FWIW, I gave this one a go & it didn't produce the link failures that Masahiro's v1 did on RISC-V... > > It really shouldn't matter, but here we are, with a build problem with > > some random old binutils on an odd platform.. > > > > AIUI, the way ld.bfd used to combine output sections may also affect > the /DISCARD/ pseudo-section, and so introducing it much earlier > results in these discards to be interpreted in a different order. > > The purpose of this change is to prevent .note.GNU-stack from deciding > the section type of the .notes output section, and so keeping it in > its own section should be sufficient. E.g., > > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -896,7 +896,7 @@ > * Otherwise, the type of .notes section would become PROGBITS > instead of NOTES. > */ > #define NOTES \ > - /DISCARD/ : { *(.note.GNU-stack) } \ > + .note.GNU-stack : { *(.note.GNU-stack) } \ > .notes : AT(ADDR(.notes) - LOAD_OFFSET) { \ > BOUNDED_SECTION_BY(.note.*, _notes) \ > } NOTES_HEADERS \ > > The .note.GNU-stack has zero size, so the result should be the same. ...and this one doesn't move DISCARDS around either, so also shouldn't hit that issue. Famous last words, so I did run it through a config that produced the link failures before & it was fine.