From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] gcc, ARM, -fdata-sections -fmerge-constants and strings
Date: Mon, 20 Aug 2012 09:55:08 -0700 [thread overview]
Message-ID: <20120820165508.GA7177@bill-the-cat> (raw)
Hey all,
As I just mentioned in another thread, gcc bug #54303 [1] causes us
problems. -fmerge-constants is an optimization enabled in most levels.
On some platforms such as x86_64, when used with -fdata-sections it
means that each set of "strings" in a function will result in a
per-function .rodata.strN.N section. Later when a function isn't used
these sections can also be garbage collected. However, on ARM this
isn't what happens. All strings for an object file are collected into a
single .rodata.strN.N section. Further, these sections are combined
again when we link our library. This means that we can only garbage
collect strings for a given library when none of them are used. This is
OK in some cases as we luck out and don't need any of the functions with
printf/puts. In other cases, such as if we move the SPL framework to
common/ all of the strings we need will be retained. This pushes us
over the size limit in some cases, along with being a flat-out bug.
As this is a bug, and something that is handled correctly on other
platforms my hope is that fixing the problem won't be hard for someone
that knows the toolchain and eventually we can set a minimum requirement
on a gcc without this bug. A work-around for this would be to disable
-fmerge-constants but this results in a larger SPL binary, but not so
large as when we collected nothing. It is larger than being careful
about where we place source files, so I would only suggest this as a
work-around once we have a fixed gcc available.
[1]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
--
Tom
reply other threads:[~2012-08-20 16:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20120820165508.GA7177@bill-the-cat \
--to=trini@ti.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.