From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC
Date: Sun, 23 Jun 2019 20:23:08 +0200 [thread overview]
Message-ID: <20190623202308.536031c8@windsurf> (raw)
In-Reply-To: <20190113141329.4d526438@windsurf.home>
Hello,
On Sun, 13 Jan 2019 14:13:29 +0100
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> I'm sorry but this doesn't make sense to me. -fPIC is for Position
> Independent Code, which is needed when building shared libraries. Here
> we are building with -static on Cortex-M which doesn't even have
> support for shared libraries. So building with -fPIC doesn't make sense
> I believe. It seems to be more a workaround than a real fix.
>
> Perhaps this should be discussed with upstream binutils, or at least a
> proper investigation be done about those relocation types ?
OK, so I had a closer look into this, finally.
What happens from my understanding is that building gnuchess with
optimization enabled (at least -O2) causes some movt/movw instructions
to be generated in the move.o object file:
380: f240 0c00 movw ip, #0
388: f2c0 0c00 movt ip, #0
These instructions refer to a global variable called PawnHashKey,
declared in another C file. Because of it being a global variable, a
relocation is added for those instructions:
00000380 00003f2f R_ARM_THM_MOVW_AB 00000000 PawnHashKey
00000388 00003f30 R_ARM_THM_MOVT_AB 00000000 PawnHashKey
00000464 00003f2f R_ARM_THM_MOVW_AB 00000000 PawnHashKey
00000470 00003f30 R_ARM_THM_MOVT_AB 00000000 PawnHashKey
And the problem is that those special relocation types are not
understood by elf2flt.
If you change the optimization flag to -O0, then the problem doesn't
occur because these movt/movw instructions are not generated. The fact
that -fPIC also works around the problem is probably due to the fact
that in a Position Independent logic, such relocations maybe don't
exist (?) or perhaps it was pure luck that the generated code was
different.
Interestingly, Romain Naour also faced this issue a while ago when
building binutils on Cortex-M, and that lead to commit
49f574237983ae2e69e4a4c43df7be98902a63be. Romain reported a bug to
binutils (https://sourceware.org/bugzilla/show_bug.cgi?id=20552), but
now I believe that the bug report is incorrect: the actual issue is in
elf2flt.
For example, the Linux kernel module loading code has support for these
relocation types:
https://elixir.bootlin.com/linux/v4.5/source/arch/arm/kernel/module.c#L258
so they seem to be legitimate.
Therefore I guess the issue is in elf2flt, and I reported a bug at
https://github.com/uclinux-dev/elf2flt/issues/11.
In the mean time, I'm not sure what to do. Indeed, we don't care about
gnuchess on Cortex-M, but the same issue affects building binutils,
which may be a bit more important (for libbfd).
Should we simply add a work-around in gnuchess, to build in -O0 for the
time being ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-06-23 18:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-12 17:55 [Buildroot] [PATCH v2,1/1] gnuchess: needs -fPIC Fabrice Fontaine
2019-01-13 13:13 ` Thomas Petazzoni
2019-01-23 14:21 ` Arnout Vandecappelle
2019-02-04 17:55 ` Peter Korsgaard
2019-06-23 18:23 ` Thomas Petazzoni [this message]
2019-06-25 21:04 ` Peter Korsgaard
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=20190623202308.536031c8@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.