All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] SPL size issues on OMAP4
Date: Thu, 11 Jul 2013 13:29:39 -0400	[thread overview]
Message-ID: <20130711172939.GK13531@bill-the-cat> (raw)
In-Reply-To: <CAB7CE35-EBF8-44E2-88D5-D4B66B76E494@prograde.net>

On Thu, Jul 11, 2013 at 01:01:30PM -0400, Michael Cashwell wrote:
> Greetings,
> 
> I've been absent for a while and couldn't find a way to search the
> list archives so I apologize if this has already been discussed?
> 
> I've been fighting the SPL binary growing too large on OMAP4 (using
> custom configs and features). It's annoying that too large just fails
> to run with no build or runtime notice. But that's a different issue.

What version are you using?  When SPL is too large a build-time failure
is expected.

> My main issue is that in looking through the map for SPL I've repeatedly found code that I don't need and have a pretty good handle on that. My issue is that code that is compiled but eliminated because it's not called leaves behind all of its anonymous strings ("like this"). In my latest build I have the following sections that are all anonymous strings:

This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 which seems to
have gotten little attention after initial triage.  I guess I need to
find a little time to show it's still there.

[snip]
> Is there a work around I haven't thought of? I'm thinking along the
> lines of disabling all printfs in SPL in the hope that will take the
> strings away (since many are some sort of debug / progress message).

One option would be to add a "disable all output" option to SPL that
would get all of the strings dropped.  I'm not sure how cleanly this can
be done, but I know it has been done.

Another option would be to do some careful splitting and #ifdef'ery of
files so that we can just never link in the stuff with strings we don't
need.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130711/8fd3d228/attachment.pgp>

  reply	other threads:[~2013-07-11 17:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-11 17:01 [U-Boot] SPL size issues on OMAP4 Michael Cashwell
2013-07-11 17:29 ` Tom Rini [this message]
2013-07-12 21:03   ` Michael Cashwell
2013-07-12 21:14     ` Michael Trimarchi
     [not found] ` <51DEEC6A.2050608@amarulasolutions.com>
2013-07-12 10:26   ` Michael Trimarchi

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=20130711172939.GK13531@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.