[U-Boot,1/5] x86: Fix compilation on 64-bit build machines

From: Graeme Russ <graeme.russ@gmail.com>

Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 Makefile                     |    1 +
 arch/x86/cpu/config.mk       |    3 ++-
 examples/standalone/Makefile |    2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

Hi Graeme,

On Tue, Nov 27, 2012 at 5:38 PM, Simon Glass <sjg@chromium.org> wrote:
> From: Graeme Russ <graeme.russ@gmail.com>
>
> Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  Makefile                     |    1 +
>  arch/x86/cpu/config.mk       |    3 ++-
>  examples/standalone/Makefile |    2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 1a17be9..2ad5cc5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -35,6 +35,7 @@ VERSION_FILE = $(obj)include/generated/version_autogenerated.h
>
>  HOSTARCH := $(shell uname -m | \
>         sed -e s/i.86/x86/ \
> +           -e s/x86_64/x86/ \
>             -e s/sun4u/sparc64/ \
>             -e s/arm.*/arm/ \
>             -e s/sa110/arm/ \
> diff --git a/arch/x86/cpu/config.mk b/arch/x86/cpu/config.mk
> index c00f867..092de68 100644
> --- a/arch/x86/cpu/config.mk
> +++ b/arch/x86/cpu/config.mk
> @@ -23,7 +23,8 @@
>
>  CROSS_COMPILE ?= i386-linux-
>
> -PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror
> +PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror -m32
> +PLATFORM_LDFLAGS += -m elf_i386
>
>  # DO NOT MODIFY THE FOLLOWING UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!
>  LDPPFLAGS += -DRESET_SEG_START=0xffff0000
> diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile
> index baaa2fb..7c1ea5c 100644
> --- a/examples/standalone/Makefile
> +++ b/examples/standalone/Makefile
> @@ -98,7 +98,7 @@ $(ELF):
>  $(obj)%:       $(obj)%.o $(LIB)
>                 $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \
>                         -o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
> -                       -L$(gcclibdir) -lgcc
> +                       -L$(USE_PRIVATE_LIBGCC) -lgcc

This forces all archs to use a private libgcc here, right? Is that the
intention? It seems to break some of the powerpc boards with my
eldk-5.2.1 toolchain. I'm not sure of the runes to get U-Boot to
compile with a 64-bit toolchain. I think it might be best to
completely get to the bottom of this rather than applying part of this
patch.

So please can you point me to the x86 compiler you tested with?

>
>  $(SREC):
>  $(obj)%.srec:  $(obj)%
> --
> 1.7.7.3
>

Regards,
Simon

Hi Simon,

On Thu, Nov 29, 2012 at 6:46 AM, Simon Glass <sjg@chromium.org> wrote:

> Hi Graeme,
>
> On Tue, Nov 27, 2012 at 5:38 PM, Simon Glass <sjg@chromium.org> wrote:
> > From: Graeme Russ <graeme.russ@gmail.com>
>

[snip]


> > diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile
> > index baaa2fb..7c1ea5c 100644
> > --- a/examples/standalone/Makefile
> > +++ b/examples/standalone/Makefile
> > @@ -98,7 +98,7 @@ $(ELF):
> >  $(obj)%:       $(obj)%.o $(LIB)
> >                 $(LD) $(LDFLAGS) -g -Ttext
> $(CONFIG_STANDALONE_LOAD_ADDR) \
> >                         -o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $<
> $(LIB) \
> > -                       -L$(gcclibdir) -lgcc
> > +                       -L$(USE_PRIVATE_LIBGCC) -lgcc
>
> This forces all archs to use a private libgcc here, right? Is that the
> intention? It seems to break some of the powerpc boards with my
>

Eeep - no, that was not the intent. I did this so long ago I can't even
remember why I did the USE_PRIVATE_LIBGCC


> eldk-5.2.1 toolchain. I'm not sure of the runes to get U-Boot to
> compile with a 64-bit toolchain. I think it might be best to
> completely get to the bottom of this rather than applying part of this
> patch.
>
> So please can you point me to the x86 compiler you tested with?
>

All my building is done with the latest gcc the ships with Fedora 17 (can't
recall the version off the top of my head)

Regards,

Graeme

Hi Simon,


On Thu, Nov 29, 2012 at 8:18 AM, Graeme Russ <graeme.russ@gmail.com> wrote:
>
> Hi Simon,
>
> On Thu, Nov 29, 2012 at 6:46 AM, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Graeme,
>>
>> On Tue, Nov 27, 2012 at 5:38 PM, Simon Glass <sjg@chromium.org> wrote:
>> > From: Graeme Russ <graeme.russ@gmail.com>
>
>
> [snip]
>
>>
>> > diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile
>> > index baaa2fb..7c1ea5c 100644
>> > --- a/examples/standalone/Makefile
>> > +++ b/examples/standalone/Makefile
>> > @@ -98,7 +98,7 @@ $(ELF):
>> >  $(obj)%:       $(obj)%.o $(LIB)
>> >                 $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \
>> >                         -o $@ -e $(SYM_PREFIX)$(notdir $(<:.o=)) $< $(LIB) \
>> > -                       -L$(gcclibdir) -lgcc
>> > +                       -L$(USE_PRIVATE_LIBGCC) -lgcc
>>
>> This forces all archs to use a private libgcc here, right? Is that the
>> intention? It seems to break some of the powerpc boards with my
>
>
> Eeep - no, that was not the intent. I did this so long ago I can't even
> remember why I did the USE_PRIVATE_LIBGCC

I've had a closer look, and I think this part of the patch is really a
hangover from commit 36b2409a3d469b5133d105fa12089429a1900bde (x86: Wrap
small helper functions from libgcc to avoid an ABI mismatch)

So the proper solution would be to break this patch into two patches - one
that fixes the libgcc/abi mismatch for examples/standalone and one that
fixes building on 64-bit build machines.

There might have been some discussion about the libgcc/regparm mismatch,
but I can't recall. I'm wondering if the option of dumping regparm was
considered. It really only impacts the code where there is a boundary
between .S and .c files and inline asm like in arch/x86/cpu/interrupts.c
Overall, it might be a cleaner solution

Regards,

Graeme