Le mercredi 13 juillet 2016 à 12:47 -0600, Martin Roth a écrit :
Ok, I tested updating the code from '.align x,0' to '.align x'. This updates the padding from 0x00 to nop instructions, and does work with GAS 2.26.
I've submitted a pull request for the arm-trusted-firmware repo: https://github.com/ARM-software/arm-trusted-firmware/pull/664
The discussion about the bug on the ATF github tracker seemed to indicate that ARM was not willing to solve things this way: https://github.com/ARM-software/tf-issues/issues/401
(I should have mentioned it the email too, instead of just in the GAS bug report, in case you missed it.)
I hope your pull request will be enough leverage to make them accept this solution!
Martin
On Wed, Jul 13, 2016 at 9:14 AM, Paul Kocialkowski contact@paulk.fr wrote:
Hi,
Le mercredi 13 juillet 2016 à 08:57 -0600, Martin Roth a écrit :
Thanks for posting about this. I've spent some time looking into this as well, but in my usual fashion, I didn't communicate what I found in a responsible fashion. Here's what I posted in a code review:
Looks like I didn't search long enough to find this ;)
The current binutils (2.26) is failing to build the current arm-trusted- firmware. This wasn't caught because the jenkins builders haven't been updated to the latest build tools. I tested the new release of binutils (2.26.1) and the update didn't help my build. There's a patch that should fix the issue - See this thread for an explanation of the issue and the patch:
https://www.mail-archive.com/linaro-toolchain%40lists.linaro.org/msg0568 5.ht ml
Unfortunately, a different change went into 2.26.1 at that location, so this patch doesn't directly apply.
For some reason, I didn't directly test that patch with 2.26 to see if it actually worked - I tried adding it in to 2.26.1, which did not help. I'll test it with 2.26 today, and add the patch into the toolchain build if it works.
From what I understood, that patch only allows the build to work when removing the extra 0 to .align (so using ".align x" instead of ".align x, 0"). And it was indeed crafted for an older GAS version. For 2.26, it doesn't apply either and a similar fix was already included, so the workaround above does work.
But again, we can't easily patch ATF…
We can't roll the entire toolchain back to binutils 2.25 because of the RISC-V work.
Indeed.
Is it reasonable to roll back to binutils 2.25 for just the ARM toolchain builds?
Someone should definitely try that, I have no idea whether it's a good idea off- hand. If anyone does, please speak up :)
I'm running out of time these days, but if nobody else does it, I'll probably have a go at it this week-end.
And then I need to update the toolchains on the builders and figure out how to keep them up-to-date so this doesn't happen again.
That would be nice!
Sorry I didn't post this directly to the mailing list earlier.
No problem, it was fun to dig into it. Also, since the affected devices are not public, I guess it doesn't really bother anyone. I just happened to look at it when submitting a crossgcc change, which comes out as unstable because of this issue, but that's about it.
Cheers,
Paul
On Wed, Jul 13, 2016 at 2:35 AM, Paul Kocialkowski contact@paulk.fr wrote:
We spent some time yesterday evening on IRC investigating why the ARM Trusted Firmware (ATF) doesn't build with the current toolchain from coreboot's crossgcc.
It turns out it is a complex issue on the assembler's side. I have opened a bug upstream about it, with all the details we could find: https://sourceware.org/bugzilla/show_bug.cgi?id=20364
This regression was introduced with binutils 2.26. To get the build going in the short term, we could either downgrade binutils back to 2.25 (if it still meets all dependencies from other tools) or patch ATF to replace the ".align x, 0" directives to ".align x" in include/common/asm_macros.S (not sure this is a possibility).
Cheers,
-- Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot