grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
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


  reply	other threads:[~2015-09-13  2:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 18:35 [PATCH] Ensure that MIPS target code is compiled for the O32 ABI Mark H Weaver
2015-08-21  4:05 ` Andrei Borzenkov
2015-08-22 18:04   ` Mark H Weaver
2015-08-23  9:51     ` Andrei Borzenkov
2015-08-23 17:27       ` Mark H Weaver
2015-08-24  6:50       ` [PATCH v2] " Mark H Weaver
2015-09-08 17:11         ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-09-09  1:37           ` Mark H Weaver
2015-09-13  6:32           ` Andrei Borzenkov
2015-10-09 21:14             ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-10-10  0:28               ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-10-14  4:49                 ` Andrei Borzenkov
2015-10-14 12:16                   ` Vladimir 'phcoder' Serbinenko
2015-10-14 17:57                     ` Andrei Borzenkov
2015-08-24  7:19     ` [PATCH] " Andrei Borzenkov
2015-08-24  7:57       ` Mark H Weaver
2015-08-24  8:12         ` Andrei Borzenkov
2015-08-24  9:27           ` Andrei Borzenkov
2015-08-25 18:18             ` Mark H Weaver
2015-09-11 15:06               ` Andrei Borzenkov
2015-09-13  2:41                 ` Mark H Weaver [this message]
2015-09-13  3:46                   ` Mark H Weaver
2015-09-13 14:10                   ` Andrei Borzenkov
2015-09-13 23:37                     ` Mark H Weaver
2015-09-20  4:44                       ` Andrei Borzenkov
2015-09-21 16:09                         ` Mark H Weaver
2015-09-21 17:56                           ` Andrei Borzenkov
2015-09-22 15:03                             ` Mark H Weaver
2015-09-22 17:26                               ` Andrei Borzenkov

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=87a8srjb1h.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    /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;
as well as URLs for NNTP newsgroup(s).