[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.

From: Mark H Weaver
Subject: Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
Date: Sat, 12 Sep 2015 22:41:30 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Andrei Borzenkov <address@hidden> writes:

>> ld: /tmp/conftest-efc530.o: compiled for a big endian system and target is 
>> little endian
>> ld: /tmp/conftest-efc530.o: endianness incompatible with that of the 
>> selected emulation
> This is the same problem we had on powerpc. Your binutils are set to
> use little-endian output by default; we need to explicitly enable
> either big or little endian in this case as well. Could you try
> attached patch to verify?

I'm glad to report that with your new patch, GRUB successfully builds on
GuixSD mips64el with TARGET_CC=clang.  I haven't yet tried booting it

>> Your patch works for me with gcc, although config.log shows this warning
>> when building the test program in your new code with the correct flags
>> for gcc (-mabi=32):
>>    ld: warning: cannot find entry symbol __start; defaulting to 
>> 00000000004000d0
> Well, I just reused existing checks in this case; we worry about it later.

Okay.  I guess the name of the start symbol depends on the platform and
linker.  E.g. boot/mips/loongson/fwstart.S has this:

--8<---------------cut here---------------start------------->8---
        .global start,_start,__start
--8<---------------cut here---------------end--------------->8---

Other platforms have only '_start', or both 'start' and '_start'.

>> I also worry that linking an O32 executable might be fragile on a pure
>> non-multilib N32 system such as GNU Guix, where we lack even the gcc
>> runtime library (libgcc_s) for O32.  For now it seems to work, but I
>> wonder if it might be more robust to do the test compilation with -c and
>> -freestanding?
> It is using -nostdlib; is it not enough?

The warning above makes me doubt the portability and future-proofness of
the link step of this test.  This problem could be avoided entirely by
omitting the link step.  The link step serves no purpose in this test,
and is a potential source of portability problems.

Having said that, if you prefer to keep the link step, I guess it will
probably be okay in practice to define 'start', '_start', and '__start'
as above.  Do as you think best.

Thanks for you help.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]