bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/29861] ld: Output Section Type can't be Overwritten / Documentat


From: nickc at redhat dot com
Subject: [Bug ld/29861] ld: Output Section Type can't be Overwritten / Documentation Unclear
Date: Thu, 08 Dec 2022 13:04:36 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=29861

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-12-08
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at sourceware dot org   |nickc at redhat dot com
                 CC|                            |nickc at redhat dot com

--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
Hi Philipp,

> However, GNU ld ignores this type when an output section contains input
> sections that already have a certain section type.

This is basically the result of a poorly specified new feature.  It was 
only intended to allow linker created sections to have a specific type
and no thought was given to how it might interact with incoming sections.


> The section will always be of type SHT_NOBITS, even if the linker script
> specifies
> 
>     .foobar . (TYPE=SHT_PROGBITS) :
>     {
>         *(.foobar)
>     } 

It turns out that there is a workaround.  If you add in some untyped data
then the link works as expected:

  % cat foobar.ld
  SECTIONS { .foobar . (TYPE=SHT_PROGBITS) : { BYTE (1); *(.foobar); } }
  % ld foobar.o -T foobar.ld -o fred
  % readelf -SW fred | grep foobar
  [ 1] .foobar      PROGBITS   0000000000000000 001000 000401 00  AX  0   0  1

I should note however, that if you add the data at the *end* of the section
rather than the start, you do get a warning message from the linker:

  % cat foobar.ld
  SECTIONS { .foobar . (TYPE=SHT_PROGBITS) : { *(.foobar); BYTE (1) } }
  % foobar.o -T foobar.ld -o fred
  ld: warning: section `.foobar' type changed to PROGBITS

It does still work though.

Given that this is a new(ish) feature and the fact that changing the current
behaviour might break things, I think that it would be best to just document
what currently happens.  Thus I am going to check in a patch which updates the
description of the TYPE directive to:

     Set the section type to the integer TYPE.  When generating an ELF
     output file, type names 'SHT_PROGBITS', 'SHT_STRTAB', 'SHT_NOTE',
     'SHT_NOBITS', 'SHT_INIT_ARRAY', 'SHT_FINI_ARRAY', and
     'SHT_PREINIT_ARRAY' are also allowed for TYPE.  It is the user's
     responsibility to ensure that any special requirements of the
     section type are met.

     Note - the TYPE only is used if some or all of the contents of the
     section do not have an implicit type of their own.  So for example:
            .foo . TYPE = SHT_PROGBITS { *(.bar) }
     will set the type of section '.foo' to the type of the section
     '.bar' in the input files, which may not be the SHT_PROGBITS type.
     Whereas:
            .foo . TYPE = SHT_PROGBITS { BYTE(1) }
     will set the type of '.foo' to SHT_PROGBBITS. If it is necessary to
     override the type of incoming sections and force the output section
     type then an extra piece of untyped data will be needed:
            .foo . TYPE = SHT_PROGBITS { BYTE(1); *(.bar) }

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]