input sections difference "ax" vs "axG" ?

Ian Lance Taylor iant@google.com
Wed Sep 2 19:57:52 GMT 2020


On Wed, Sep 2, 2020 at 1:04 AM Akhilesh Chirlancha
<akhileshchirlancha.linux@gmail.com> wrote:
>
> Many thanks for the clarification.
>
> Unfortunately, both the toolchain configurations and all the component sources are the same.
> Here my question is, Are there any configuration options or compiler options to support the .group option for toolchain to avoid the .gnu.linkonce sections ??

I don't know.

> and Do you think that any other dependency packages could also cause this problem, or any machine definition files ??

If your toolchain includes the GNU binutils, then, no, I don't think
any other dependency would matter.

Ian


> On Tue, Sep 1, 2020 at 10:50 PM Ian Lance Taylor <iant@google.com> wrote:
>>
>> On Tue, Sep 1, 2020 at 9:11 AM Akhilesh Chirlancha
>> <akhileshchirlancha.linux@gmail.com> wrote:
>> >
>> >
>> > Why the same ARM gcc creating 2 different types of input sections? (.gnu.linkonce.t "ax") and (.group "axG")
>> >
>> > I have 2 ARM toolchain releases. one toolchain is generating the input sections with ".gnu.linkonce.t" prefix('ax') and another toolchain is with ".group" sections('axG').
>> > And the toolchain with the .gnu.linkonce.t is throwing an error sometimes ""defined in discarded section" and "undefined reference"".
>> > I do not have any clue why it's choosing 2 different types of input sections even if there are no changes in the toolchain sources.
>> >
>> > What could be the reason behind this? If there is somewhere better for me to be looking, I would appreciate a pointer.
>>
>> .gnu.linkince and .group are two different ways of addressing the same
>> problem.  The .group approach is newer and can handle more cases.  So
>> a newer toolchain should expect to use .group.  The choice between
>> them will depend not just on the compiler, but also on whether the
>> assembler and linker support the .group option.
>>
>> You say that you have two toolchain releases, so your question as to
>> exactly why it changed might be better addressed to whoever created
>> those releases.
>>
>> Hope this helps.
>>
>> Ian


More information about the Gcc-help mailing list