Hello, After some investigation I found there were more things wrong with the way we handled the branch future relocations. I fixed these and added a linker test for ELF targets (and a duplicate entry for vxworks as we seem to skip other elf linker tests for it). As for the vxworks failures Alan spotted, I believe this is due to the relocations being treated differently, as you pointed out one uses REL and the other RELA. This leads to different relocation encodings. So for instance when a REL target encodes a relocation for 'target' it seems to do so with: A = 0 S = target whereas for RELA it uses: A = 4 S = target-4 These do get handled correctly by the linker as shown in the test added for vxworks and other elf targets. I also checked other similar relocations, such as the R_ARM_THM_JUMP24, and these behave the same way. As a side effect, this patch also removes the unnecessary 'get_value_helper' function thus also fixing PR/target 24460 @Sudi please do not commit your earlier fix. Tested on arm-none-eabi, arm-vxworks, arm-wince-pe, and arm-pe. Is this OK for trunk? bfd/ChangeLog: 2019-04-30 Andre Vieira PR/target 24460 * elf32-arm.c (get_value_helper): Remove. (elf32_arm_final_link_relocate): Fix branch future relocations. gas/ChangeLog: 2019-04-30 Andre Vieira * testsuite/gas/arm/armv8_1-m-bf.d: Allow different branch target naming conventions. * testsuite/gas/arm/armv8_1-m-bfl.d: Likewise. * testsuite/gas/arm/armv8_1-m-bfcsel.d: Likewise. * testsuite/gas/arm/armv8_1-m-loloop.d: Likewise. * testsuite/gas/arm/armv8_1-m-bf-rel.d: Skip for vxworks. * testsuite/gas/arm/armv8_1-m-bf-rela.d: New test. * testsuite/gas/arm/armv8_1-m-bfl-rel.d: Skip for vxworks. * testsuite/gas/arm/armv8_1-m-bfl-rela.d: New test. ld/ChangeLog: 2019-04-30 Andre Vieira * testsuite/ld-arm/arm-elf.exp: Add tests * testsuite/ld-arm/bfs-0.s: New test. * testsuite/ld-arm/bfs-1.s: New test. * testsuite/ld-arm/branch-futures.d: New test. On 16/04/2019 13:36, Alan Modra wrote: > On Tue, Apr 16, 2019 at 11:52:19AM +0000, Andre Simoes Dias Vieira wrote: >> Hi Alan, >> >> Thanks for the heads up. I am on holidays so I don't have much time to look at this right now. But after a quick look I think the arm-pe fails are due to objdump printing the branch targets in a different format. I'll double-check later, but it should be a case of accepting both answers. >> >> The VxWorks failures seem to be related to the relocations. I did a quick search but couldn't determine whether VxWorks uses Elf binary format. Do you reckon VxWorks should support this elf relocation? If so I'll need to look at it a bit further, otherwise I'll skip the relocation tests for VxWorks. > > VxWorks uses ELF. The difference is that unlike other ARM targets, > arm-vxworks uses rela style relocations. Very likely your new reloc > processing is broken for rela. ie. You shouldn't just sweep this > under the rug. ;-) > >> Cheers, >> Andre >> >> -----Original Message----- >> From: Alan Modra >> Sent: 16 April 2019 02:58 >> To: Andre Simoes Dias Vieira >> Cc: nickc@redhat.com; binutils@sourceware.org; nd >> Subject: Re: [PATCH, binutils, ARM, 0/16] Add support for Armv8.1-M Mainline >> >> These failures remain. >> arm-pe +FAIL: Valid Armv8.1-M Mainline BF instruction arm-pe +FAIL: Valid Armv8.1-M Mainline BFCSEL instruction arm-pe +FAIL: Valid Armv8.1-M Mainline BFL instruction arm-pe +FAIL: Valid Armv8.1-M Mainline Low Overhead loop instructions arm-vxworks +FAIL: Valid Armv8.1-M Mainline BF instruction with relocation arm-vxworks +FAIL: Valid Armv8.1-M Mainline BFL instruction with relocation >> >> -- >> Alan Modra >> Australia Development Lab, IBM >