public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Relocation issue - need help!
Date: Fri, 24 Oct 2014 10:14:39 -0400	[thread overview]
Message-ID: <87lho5lflc.fsf@nbsps.com> (raw)
In-Reply-To: <20141023131039.59826380415@gemini.denx.de> (Wolfgang Denk's message of "Thu, 23 Oct 2014 15:10:39 +0200")

On 23 Oct 2014, wd at denx.de wrote:

> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?
>
> Should we blacklist GCC 4.8.x (and 4.9.0) like the kernel folks are
> doing [1] ?
>
> [1] https://lkml.org/lkml/2014/10/10/272

My understanding is this is for a completely different issue.  The
proposed patch is,

+# if ((GCC_VERSION >= 40800 && GCC_VERSION <= 40802) || GCC_VERSION == 40900) \
+	&& defined(__arm__) && defined(CONFIG_FRAME_POINTER)
+#  error Your version of gcc miscompiles stack frames
+# endif

So, the proposed patch was blacklist gcc v4.8.[012] and 4.9.0 on the
*ARM* when frame pointer tracing is enabled.  This thread refers to a
different bug where 'sp' is adjusted for a return while the 'fp' will
still be references (for instance in a return calculation) above the
'sp'.  It is a completely different issue than the '.data.rel.ro' which
is on all architectures.

Also, if you read further in the thread, it seems that 4.9.0 does not
exhibit this problem.  The 4.9.0 was only suggested as the 'Known to
fail' of bug 58854 shows '4.9.0'.

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854

Apparently this was added during the 4.9.0 release process, but didn't
make it to the official release.  In any case, unless u-boot uses
signals and/or an interrupt stack common to the mainline, this bug would
not even affect the ARM cpus with U-boot.

On 23 Oct 2014, wd@denx.de wrote:

> 4) For the problemativ 4.8.x versions of GCC, the following patch
>   apparently solves the problem for my (MPC5200 based) board - guess
>   this would have to be applied to all .lds files...

>diff --git a/arch/powerpc/cpu/mpc5xxx/u-boot.lds b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>index cd9e23f..82c86d7 100644
>--- a/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>+++ b/arch/powerpc/cpu/mpc5xxx/u-boot.lds
>@@ -27,6 +27,8 @@ SECTIONS
>   {
>     _GOT2_TABLE_ = .;
>     KEEP(*(.got2))
>+    KEEP(*(.data.rel.ro))
>+    KEEP(*(.data.rel.ro.local))
>     KEEP(*(.got))
>     PROVIDE(_GLOBAL_OFFSET_TABLE_ = . + 4);
>     _FIXUP_TABLE_ = .;

> Given that GCC 4.9.1 apparently solves this issue I wonder which
> approach we should take?

From my perspective and reading the blog below this patch seems sensible. 

 http://www.airs.com/blog/archives/189

I assume u-boot has no MMU enabled, then all the relocations should be
similar.  This would be for all architectures though?

Fwiw,
Bill Pringlemeir.

  parent reply	other threads:[~2014-10-24 14:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 12:39 [U-Boot] Relocation issue - need help! Wolfgang Denk
2014-10-22 13:29 ` Dirk Eibach
2014-10-22 16:56   ` Wolfgang Denk
2014-10-22 17:26     ` Fabio Estevam
2014-10-22 17:28     ` Tom Rini
2014-10-22 17:39       ` Wolfgang Denk
2014-10-22 21:27       ` Pavel Machek
2014-10-22 21:46         ` Marek Vasut
2014-10-22 21:57           ` Pavel Machek
2014-10-22 22:06             ` Marek Vasut
2014-10-23  6:01     ` Dirk Eibach
2014-10-23  6:42       ` Joakim Tjernlund
2014-10-23 13:10         ` Wolfgang Denk
2014-10-23 13:42           ` Dirk Eibach
2014-10-24 14:14           ` Bill Pringlemeir [this message]
2015-09-30 18:24           ` Andy Fleming
2015-09-30 19:35             ` Marek Vasut
2015-10-01  8:57               ` Joakim Tjernlund
2015-10-06 11:17                 ` Joakim Tjernlund
2015-10-15 15:56                   ` Joakim Tjernlund
2015-10-15 21:58                     ` Tom Rini
2015-10-16  6:55                       ` Joakim Tjernlund
2015-10-16 11:47                         ` Tom Rini
2015-10-16 13:14                           ` Joakim Tjernlund
2015-10-20 21:06                             ` Andy Fleming
2015-10-20 21:21                               ` Tom Rini
2015-10-21  8:44                                 ` Joakim Tjernlund
2015-10-21 13:12                                   ` Tom Rini
2015-10-21 13:18                                     ` Joakim Tjernlund
2015-10-01 14:18             ` Wolfgang Denk
2015-10-02 22:51               ` Andy Fleming
2015-10-03  8:33                 ` Wolfgang Denk

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=87lho5lflc.fsf@nbsps.com \
    --to=bpringlemeir@nbsps.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox