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 , and found > the commit which broke it . > I now built binutils 220.127.116.1161105-1 with this commit reverted, and > was able to build musl. > >  https://sourceware.org/ml/binutils/2017-01/msg00081.html >  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.