From: Akhilesh Chirlancha <akhileshchirlancha.linux@gmail.com>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: input sections difference "ax" vs "axG" ?
Date: Wed, 2 Sep 2020 13:33:53 +0530 [thread overview]
Message-ID: <CAHJJy=WSqXXogtBz6734siOSPL8manHtj35sE9x1GORrQtbBsw@mail.gmail.com> (raw)
In-Reply-To: <CAKOQZ8w5Z2z4mKYTzMJ__wnAm0AHvV3tH918HtgeGMNU5JVQaQ@mail.gmail.com>
Hi Ian,
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 ??
and Do you think that any other dependency packages could also cause this
problem, or any machine definition files ??
-Akhilesh
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
>
next prev parent reply other threads:[~2020-09-02 8:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 16:11 Akhilesh Chirlancha
2020-09-01 17:20 ` Ian Lance Taylor
2020-09-02 8:03 ` Akhilesh Chirlancha [this message]
2020-09-02 19:57 ` Ian Lance Taylor
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='CAHJJy=WSqXXogtBz6734siOSPL8manHtj35sE9x1GORrQtbBsw@mail.gmail.com' \
--to=akhileshchirlancha.linux@gmail.com \
--cc=gcc-help@gcc.gnu.org \
--cc=iant@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).