diff mbox series

[v3,2/9] vmlinux.lds.h: Add .symtab, .strtab, and .shstrtab to STABS_DEBUG

Message ID 20200624014940.1204448-3-keescook@chromium.org (mailing list archive)
State New, archived
Headers show
Series Warn on orphan section placement | expand

Commit Message

Kees Cook June 24, 2020, 1:49 a.m. UTC
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
order[1].)

ld.lld: warning: <internal>:(.symtab) is being placed in '.symtab'
ld.lld: warning: <internal>:(.shstrtab) is being placed in '.shstrtab'
ld.lld: warning: <internal>:(.strtab) is being placed in '.strtab'

[1] https://lore.kernel.org/lkml/20200622224928.o2a7jkq33guxfci4@google.com/

Reported-by: Fangrui Song <maskray@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/asm-generic/vmlinux.lds.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Arvind Sankar June 24, 2020, 3:39 p.m. UTC | #1
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.
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?

> order[1].)
> 
> ld.lld: warning: <internal>:(.symtab) is being placed in '.symtab'
> ld.lld: warning: <internal>:(.shstrtab) is being placed in '.shstrtab'
> ld.lld: warning: <internal>:(.strtab) is being placed in '.strtab'
> 
> [1] https://lore.kernel.org/lkml/20200622224928.o2a7jkq33guxfci4@google.com/
> 
> Reported-by: Fangrui Song <maskray@google.com>
> Reviewed-by: Fangrui Song <maskray@google.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/asm-generic/vmlinux.lds.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 1248a206be8d..8e71757f485b 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -792,7 +792,10 @@
>  		.stab.exclstr 0 : { *(.stab.exclstr) }			\
>  		.stab.index 0 : { *(.stab.index) }			\
>  		.stab.indexstr 0 : { *(.stab.indexstr) }		\
> -		.comment 0 : { *(.comment) }
> +		.comment 0 : { *(.comment) }				\
> +		.symtab 0 : { *(.symtab) }				\
> +		.strtab 0 : { *(.strtab) }				\
> +		.shstrtab 0 : { *(.shstrtab) }
>  
>  #ifdef CONFIG_GENERIC_BUG
>  #define BUG_TABLE							\
> -- 
> 2.25.1
>
Fangrui Song June 24, 2020, 4:16 p.m. UTC | #2
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.

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.)

>> order[1].)
>>
>> ld.lld: warning: <internal>:(.symtab) is being placed in '.symtab'
>> ld.lld: warning: <internal>:(.shstrtab) is being placed in '.shstrtab'
>> ld.lld: warning: <internal>:(.strtab) is being placed in '.strtab'
>>
>> [1] https://lore.kernel.org/lkml/20200622224928.o2a7jkq33guxfci4@google.com/
>>
>> Reported-by: Fangrui Song <maskray@google.com>
>> Reviewed-by: Fangrui Song <maskray@google.com>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  include/asm-generic/vmlinux.lds.h | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 1248a206be8d..8e71757f485b 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -792,7 +792,10 @@
>>  		.stab.exclstr 0 : { *(.stab.exclstr) }			\
>>  		.stab.index 0 : { *(.stab.index) }			\
>>  		.stab.indexstr 0 : { *(.stab.indexstr) }		\
>> -		.comment 0 : { *(.comment) }
>> +		.comment 0 : { *(.comment) }				\
>> +		.symtab 0 : { *(.symtab) }				\
>> +		.strtab 0 : { *(.strtab) }				\
>> +		.shstrtab 0 : { *(.shstrtab) }
>>
>>  #ifdef CONFIG_GENERIC_BUG
>>  #define BUG_TABLE							\
>> --
>> 2.25.1
>>
Arvind Sankar June 24, 2020, 5:11 p.m. UTC | #3
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?

> 
> 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.
Fangrui Song June 24, 2020, 5:26 p.m. UTC | #4
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.
Arvind Sankar June 24, 2020, 5:35 p.m. UTC | #5
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.
diff mbox series

Patch

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 1248a206be8d..8e71757f485b 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -792,7 +792,10 @@ 
 		.stab.exclstr 0 : { *(.stab.exclstr) }			\
 		.stab.index 0 : { *(.stab.index) }			\
 		.stab.indexstr 0 : { *(.stab.indexstr) }		\
-		.comment 0 : { *(.comment) }
+		.comment 0 : { *(.comment) }				\
+		.symtab 0 : { *(.symtab) }				\
+		.strtab 0 : { *(.strtab) }				\
+		.shstrtab 0 : { *(.shstrtab) }
 
 #ifdef CONFIG_GENERIC_BUG
 #define BUG_TABLE							\