From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bill Pringlemeir <bpringlemeir@nbsps.com>
Date: Fri, 24 Oct 2014 10:14:39 -0400
Subject: [U-Boot] Relocation issue - need help!
In-Reply-To: <20141023131039.59826380415@gemini.denx.de> (Wolfgang Denk's
	message of "Thu, 23 Oct 2014 15:10:39 +0200")
References: <20141022123929.5FD0B3834D1@gemini.denx.de>
	<CANVMifLGzKz+=-K-E9_sSXBxpYPdG1YqEXc-tsCApi7WVxQAHg@mail.gmail.com>
	<20141022165611.ED5203832AC@gemini.denx.de>
	<CANVMif+B2C+uG4mFVf-bUoMT3fHxQOUbGds7wc9A6ugyw92-Ww@mail.gmail.com>
	<OF14C3D470.864842B6-ONC1257D7A.002471AC-C1257D7A.0024DEC4@transmode.se>
	<20141023131039.59826380415@gemini.denx.de>
Message-ID: <87lho5lflc.fsf@nbsps.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.