All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Fangrui Song <maskray@google.com>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	Kees Cook <keescook@chromium.org>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Peter Collingbourne <pcc@google.com>,
	James Morse <james.morse@arm.com>, Borislav Petkov <bp@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	x86@kernel.org, clang-built-linux@googlegroups.com,
	linux-arch@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/9] vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to STABS_DEBUG
Date: Wed, 24 Jun 2020 13:35:09 -0400	[thread overview]
Message-ID: <20200624173509.GA1460341@rani.riverdale.lan> (raw)
In-Reply-To: <20200624172620.654hhjetiyzpgoxw@google.com>

On Wed, Jun 24, 2020 at 10:26:20AM -0700, Fangrui Song wrote:
> 
> On 2020-06-24, Arvind Sankar wrote:
> >On Wed, Jun 24, 2020 at 09:16:43AM -0700, Fangrui Song wrote:
> >>
> >> On 2020-06-24, Arvind Sankar wrote:
> >> >On Tue, Jun 23, 2020 at 06:49:33PM -0700, Kees Cook wrote:
> >> >> When linking vmlinux with LLD, the synthetic sections .symtab, .strtab,
> >> >> and .shstrtab are listed as orphaned. Add them to the STABS_DEBUG section
> >> >> so there will be no warnings when --orphan-handling=warn is used more
> >> >> widely. (They are added above comment as it is the more common
> >> >
> >> >Nit 1: is "after .comment" better than "above comment"? It's above in the
> >> >sense of higher file offset, but it's below in readelf output.
> >>
> >> I mean this order:)
> >>
> >>    .comment
> >>    .symtab
> >>    .shstrtab
> >>    .strtab
> >>
> >> This is the case in the absence of a linker script if at least one object file has .comment (mostly for GCC/clang version information) or the linker is LLD which adds a .comment
> >>
> >> >Nit 2: These aren't actually debugging sections, no? Is it better to add
> >> >a new macro for it, and is there any plan to stop LLD from warning about
> >> >them?
> >>
> >> https://reviews.llvm.org/D75149 "[ELF] --orphan-handling=: don't warn/error for unused synthesized sections"
> >> described that .symtab .shstrtab .strtab are different in GNU ld.
> >> Since many other GNU ld synthesized sections (.rela.dyn .plt ...) can be renamed or dropped
> >> via output section descriptions, I don't understand why the 3 sections
> >> can't be customized.
> >
> >So IIUC, lld will now warn about .rela.dyn etc only if they're non-empty?
> 
> HEAD and future 11.0.0 will not warn about unused synthesized sections
> like .rela.dyn
> 
> For most synthesized sections, empty = unused.
> 
> >>
> >> I created a feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26168
> >> (If this is supported, it is a consistent behavior to warn for orphan
> >> .symtab/.strtab/.shstrtab
> >>
> >> There may be 50% chance that the maintainer decides that "LLD diverges"
> >> I would disagree: there is no fundamental problems with .symtab/.strtab/.shstrtab which make them special in output section descriptions or orphan handling.)
> >>
> >
> >.shstrtab is a little special in that it can't be discarded if the ELF
> >file contains any sections at all. But yeah, there's no reason they
> >can't be renamed or placed in a custom location in the file.
> 
> https://sourceware.org/pipermail/binutils/2020-March/000179.html
> proposes -z nosectionheader. With this option, I believe .shstrtab is
> not needed. /DISCARD/ : { *(.shstrtab) }  should achieve a similar effect.

oh wow.

WARNING: multiple messages have this Message-ID (diff)
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Fangrui Song <maskray@google.com>
Cc: Arvind Sankar <nivedita@alum.mit.edu>,
	Kees Cook <keescook@chromium.org>, Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Peter Collingbourne <pcc@google.com>,
	James Morse <james.morse@arm.com>, Borislav Petkov <bp@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	x86@kernel.org, clang-built-linux@googlegroups.com,
	linux-arch@vger.kernel.org, linux-efi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-kernel@vge
Subject: Re: [PATCH v3 2/9] vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to STABS_DEBUG
Date: Wed, 24 Jun 2020 13:35:09 -0400	[thread overview]
Message-ID: <20200624173509.GA1460341@rani.riverdale.lan> (raw)
In-Reply-To: <20200624172620.654hhjetiyzpgoxw@google.com>

On Wed, Jun 24, 2020 at 10:26:20AM -0700, Fangrui Song wrote:
> 
> On 2020-06-24, Arvind Sankar wrote:
> >On Wed, Jun 24, 2020 at 09:16:43AM -0700, Fangrui Song wrote:
> >>
> >> On 2020-06-24, Arvind Sankar wrote:
> >> >On Tue, Jun 23, 2020 at 06:49:33PM -0700, Kees Cook wrote:
> >> >> When linking vmlinux with LLD, the synthetic sections .symtab, .strtab,
> >> >> and .shstrtab are listed as orphaned. Add them to the STABS_DEBUG section
> >> >> so there will be no warnings when --orphan-handling=warn is used more
> >> >> widely. (They are added above comment as it is the more common
> >> >
> >> >Nit 1: is "after .comment" better than "above comment"? It's above in the
> >> >sense of higher file offset, but it's below in readelf output.
> >>
> >> I mean this order:)
> >>
> >>    .comment
> >>    .symtab
> >>    .shstrtab
> >>    .strtab
> >>
> >> This is the case in the absence of a linker script if at least one object file has .comment (mostly for GCC/clang version information) or the linker is LLD which adds a .comment
> >>
> >> >Nit 2: These aren't actually debugging sections, no? Is it better to add
> >> >a new macro for it, and is there any plan to stop LLD from warning about
> >> >them?
> >>
> >> https://reviews.llvm.org/D75149 "[ELF] --orphan-handling=: don't warn/error for unused synthesized sections"
> >> described that .symtab .shstrtab .strtab are different in GNU ld.
> >> Since many other GNU ld synthesized sections (.rela.dyn .plt ...) can be renamed or dropped
> >> via output section descriptions, I don't understand why the 3 sections
> >> can't be customized.
> >
> >So IIUC, lld will now warn about .rela.dyn etc only if they're non-empty?
> 
> HEAD and future 11.0.0 will not warn about unused synthesized sections
> like .rela.dyn
> 
> For most synthesized sections, empty = unused.
> 
> >>
> >> I created a feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26168
> >> (If this is supported, it is a consistent behavior to warn for orphan
> >> .symtab/.strtab/.shstrtab
> >>
> >> There may be 50% chance that the maintainer decides that "LLD diverges"
> >> I would disagree: there is no fundamental problems with .symtab/.strtab/.shstrtab which make them special in output section descriptions or orphan handling.)
> >>
> >
> >.shstrtab is a little special in that it can't be discarded if the ELF
> >file contains any sections at all. But yeah, there's no reason they
> >can't be renamed or placed in a custom location in the file.
> 
> https://sourceware.org/pipermail/binutils/2020-March/000179.html
> proposes -z nosectionheader. With this option, I believe .shstrtab is
> not needed. /DISCARD/ : { *(.shstrtab) }  should achieve a similar effect.

oh wow.

WARNING: multiple messages have this Message-ID (diff)
From: Arvind Sankar <nivedita@alum.mit.edu>
To: Fangrui Song <maskray@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-efi@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Arvind Sankar <nivedita@alum.mit.edu>,
	Will Deacon <will@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arch@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>,
	x86@kernel.org, Russell King <linux@armlinux.org.uk>,
	Ard Biesheuvel <ardb@kernel.org>,
	clang-built-linux@googlegroups.com,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@suse.de>,
	Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Peter Collingbourne <pcc@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org, James Morse <james.morse@arm.com>
Subject: Re: [PATCH v3 2/9] vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to STABS_DEBUG
Date: Wed, 24 Jun 2020 13:35:09 -0400	[thread overview]
Message-ID: <20200624173509.GA1460341@rani.riverdale.lan> (raw)
In-Reply-To: <20200624172620.654hhjetiyzpgoxw@google.com>

On Wed, Jun 24, 2020 at 10:26:20AM -0700, Fangrui Song wrote:
> 
> On 2020-06-24, Arvind Sankar wrote:
> >On Wed, Jun 24, 2020 at 09:16:43AM -0700, Fangrui Song wrote:
> >>
> >> On 2020-06-24, Arvind Sankar wrote:
> >> >On Tue, Jun 23, 2020 at 06:49:33PM -0700, Kees Cook wrote:
> >> >> When linking vmlinux with LLD, the synthetic sections .symtab, .strtab,
> >> >> and .shstrtab are listed as orphaned. Add them to the STABS_DEBUG section
> >> >> so there will be no warnings when --orphan-handling=warn is used more
> >> >> widely. (They are added above comment as it is the more common
> >> >
> >> >Nit 1: is "after .comment" better than "above comment"? It's above in the
> >> >sense of higher file offset, but it's below in readelf output.
> >>
> >> I mean this order:)
> >>
> >>    .comment
> >>    .symtab
> >>    .shstrtab
> >>    .strtab
> >>
> >> This is the case in the absence of a linker script if at least one object file has .comment (mostly for GCC/clang version information) or the linker is LLD which adds a .comment
> >>
> >> >Nit 2: These aren't actually debugging sections, no? Is it better to add
> >> >a new macro for it, and is there any plan to stop LLD from warning about
> >> >them?
> >>
> >> https://reviews.llvm.org/D75149 "[ELF] --orphan-handling=: don't warn/error for unused synthesized sections"
> >> described that .symtab .shstrtab .strtab are different in GNU ld.
> >> Since many other GNU ld synthesized sections (.rela.dyn .plt ...) can be renamed or dropped
> >> via output section descriptions, I don't understand why the 3 sections
> >> can't be customized.
> >
> >So IIUC, lld will now warn about .rela.dyn etc only if they're non-empty?
> 
> HEAD and future 11.0.0 will not warn about unused synthesized sections
> like .rela.dyn
> 
> For most synthesized sections, empty = unused.
> 
> >>
> >> I created a feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26168
> >> (If this is supported, it is a consistent behavior to warn for orphan
> >> .symtab/.strtab/.shstrtab
> >>
> >> There may be 50% chance that the maintainer decides that "LLD diverges"
> >> I would disagree: there is no fundamental problems with .symtab/.strtab/.shstrtab which make them special in output section descriptions or orphan handling.)
> >>
> >
> >.shstrtab is a little special in that it can't be discarded if the ELF
> >file contains any sections at all. But yeah, there's no reason they
> >can't be renamed or placed in a custom location in the file.
> 
> https://sourceware.org/pipermail/binutils/2020-March/000179.html
> proposes -z nosectionheader. With this option, I believe .shstrtab is
> not needed. /DISCARD/ : { *(.shstrtab) }  should achieve a similar effect.

oh wow.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-06-24 17:35 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  1:49 [PATCH v3 0/9] Warn on orphan section placement Kees Cook
2020-06-24  1:49 ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 1/9] vmlinux.lds.h: Add .gnu.version* to DISCARDS Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 2/9] vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to STABS_DEBUG Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24 15:39   ` Arvind Sankar
2020-06-24 15:39     ` Arvind Sankar
2020-06-24 15:39     ` Arvind Sankar
2020-06-24 16:16     ` Fangrui Song
2020-06-24 16:16       ` Fangrui Song
2020-06-24 17:11       ` Arvind Sankar
2020-06-24 17:11         ` Arvind Sankar
2020-06-24 17:11         ` Arvind Sankar
2020-06-24 17:26         ` Fangrui Song
2020-06-24 17:26           ` Fangrui Song
2020-06-24 17:35           ` Arvind Sankar [this message]
2020-06-24 17:35             ` Arvind Sankar
2020-06-24 17:35             ` Arvind Sankar
2020-06-24  1:49 ` [PATCH v3 3/9] efi/libstub: Remove .note.gnu.property Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  3:31   ` Fangrui Song
2020-06-24  3:31     ` Fangrui Song
2020-06-24  4:44     ` Kees Cook
2020-06-24  4:44       ` Kees Cook
2020-06-24 10:43       ` Will Deacon
2020-06-24 10:43         ` Will Deacon
2020-06-24 10:46         ` Ard Biesheuvel
2020-06-24 10:46           ` Ard Biesheuvel
2020-06-24 10:46           ` Ard Biesheuvel
2020-06-24 11:26           ` Will Deacon
2020-06-24 11:26             ` Will Deacon
2020-06-24 11:26             ` Will Deacon
2020-06-24 13:48             ` Dave Martin
2020-06-24 13:48               ` Dave Martin
2020-06-24 13:48               ` Dave Martin
2020-06-24 15:26               ` Will Deacon
2020-06-24 15:26                 ` Will Deacon
2020-06-24 15:26                 ` Will Deacon
2020-06-24 16:26                 ` Dave Martin
2020-06-24 16:26                   ` Dave Martin
2020-06-24 16:26                   ` Dave Martin
2020-06-24 15:21           ` Kees Cook
2020-06-24 15:21             ` Kees Cook
2020-06-24 15:21             ` Kees Cook
2020-06-24 15:31             ` Ard Biesheuvel
2020-06-24 15:31               ` Ard Biesheuvel
2020-06-24 15:31               ` Ard Biesheuvel
2020-06-24 15:45               ` Kees Cook
2020-06-24 15:45                 ` Kees Cook
2020-06-24 15:45                 ` Kees Cook
2020-06-24 15:48                 ` Ard Biesheuvel
2020-06-24 15:48                   ` Ard Biesheuvel
2020-06-24 15:48                   ` Ard Biesheuvel
2020-06-24 16:29                   ` Dave Martin
2020-06-24 16:29                     ` Dave Martin
2020-06-24 16:29                     ` Dave Martin
2020-06-24 16:40                     ` Ard Biesheuvel
2020-06-24 16:40                       ` Ard Biesheuvel
2020-06-24 16:40                       ` Ard Biesheuvel
2020-06-24 17:16                       ` Dave Martin
2020-06-24 17:16                         ` Dave Martin
2020-06-24 17:16                         ` Dave Martin
2020-06-24 18:23                         ` Ard Biesheuvel
2020-06-24 18:23                           ` Ard Biesheuvel
2020-06-24 18:23                           ` Ard Biesheuvel
2020-06-24 18:57                           ` Ard Biesheuvel
2020-06-24 18:57                             ` Ard Biesheuvel
2020-06-24 18:57                             ` Ard Biesheuvel
2020-06-24  1:49 ` [PATCH v3 4/9] x86/build: Warn on orphan section placement Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24 18:36   ` kernel test robot
2020-06-27 15:44     ` Kees Cook
2020-06-27 15:44       ` Kees Cook
2020-06-29 14:54       ` Marco Elver
2020-06-29 14:54         ` Marco Elver
2020-06-29 15:26         ` Kees Cook
2020-06-29 15:26           ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 5/9] x86/boot: " Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 6/9] arm/build: " Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 7/9] arm/boot: " Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 8/9] arm64/build: Use common DISCARDS in linker script Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  1:49 ` [PATCH v3 9/9] arm64/build: Warn on orphan section placement Kees Cook
2020-06-24  1:49   ` Kees Cook
2020-06-24  7:57   ` Will Deacon
2020-06-24  7:57     ` Will Deacon
2020-06-24 15:36     ` Kees Cook
2020-06-24 15:36       ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200624173509.GA1460341@rani.riverdale.lan \
    --to=nivedita@alum.mit.edu \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=james.morse@arm.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=mingo@redhat.com \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=pcc@google.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.