Re: musl 1.1.16 build failure on armhf

[Szabolcs Nagy <nsz@port70.net>]

* Reiner Herrmann <reiner@reiner-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..)