[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170109130253.GK17692@port70.net>
Date: Mon, 9 Jan 2017 14:02:53 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>
Subject: Re: musl 1.1.16 build failure on armhf
* Reiner Herrmann <reiner@...ner-h.de> [2017-01-07 16:19:27 +0100]:
> On Wed, Jan 04, 2017 at 04:36:46PM -0500, Rich Felker wrote:
> > Can you find the commit that broke it and figure out if it's a
> > binutils bug or an intentional change we need to find a way to work
> > with?
>
> Someone posted the bug also on the binutils mailinglist [0], and found
> the commit which broke it [1].
> I now built binutils 2.27.51.20161105-1 with this commit reverted, and
> was able to build musl.
>
> [0] https://sourceware.org/ml/binutils/2017-01/msg00081.html
> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bada43421274615d0d5f629a61a60b7daa71bc15
the regression was not intentional i think, but that
change fixes a real issue.
.arch foo
x
.arch bar
y
assembles x according to arch foo, and y according to
arch bar and the final arch attribute of the object is
bar.
however there is a second fixup pass in arm gas and
that fixes both x and y according to the final object
attribute and that can fail on x (the patch happens to
tighten some checks there)
this may be fixed in gas by considering .arch settings
during the second pass, but it is probably non-trivial
code change (second pass does not have the context of
the original code now)
on the musl side a possible workaround is to use the
.object_arch directive which only affects the final
arch attribute, but not the second pass.
(but it has to be evaluated on all the different
toolchains and assemblers to do the right thing..)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
