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

From: Mark H Weaver <mhw@netris.org>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH] Ensure that MIPS target code is compiled for the O32 ABI.
Date: Sat, 12 Sep 2015 22:41:30 -0400	[thread overview]
Message-ID: <87a8srjb1h.fsf@netris.org> (raw)
In-Reply-To: <55F2EDF4.4040207@gmail.com> (Andrei Borzenkov's message of "Fri,  11 Sep 2015 18:06:28 +0300")

Andrei Borzenkov <arvidjaar@gmail.com> 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
though.

>> 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
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.

      Mark