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