[PATCH v3 1/2] arm, objdump: Make objdump use bfd's machine detection to drive disassembly

[Andre Vieira (lists)]

Hi Alan

On 12/11/2024 06:30, Alan Modra wrote:
> On Fri, Nov 01, 2024 at 10:26:18AM +0000, Andre Vieira wrote:
>> -      if ((info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0)
>> +      if (info->flavour != bfd_target_elf_flavour
>> +	  && (info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0)
>>
> It looks like this change caused arm-nacl regressions:
> +FAIL: ARM-ARM farcall
> +FAIL: ARM-ARM farcall (PIC veneer)
> +FAIL: ARM-ARM farcall (BE8)
> +FAIL: ARM-ARM farcall (BE)
> +FAIL: Long branch with mixed text and data
> 

Had a look at these and the farcall-arm-arm-nacl*.d files seem to expect 
the disassembly past 'bx ip' to be nop + bkpt. However, bkpt is armv5T+ 
and the nop is armv6t2+. Since the assembly file is compiled without an 
-march it defaults to armv4t.
If nop+bkpt is the expected behaviour and we want to test for it, we 
should probably assemble for armv6t2.

However adding '#as: -march=armv6t2' to farcall-arm-nacl.d doesn't seem 
to help, the linker dejagnu handling seems to be a bit 'different'. We 
could add .arch armv6t2 to farcall-arm-arm.s. Unless you know how to get 
the #as stuff to work on those?

Alternatively, we could ignore the nop+bkpt in the assembly check for 
the farcall-*-nacle.d files if that's not relevant? Not familiar with 
this functionality, but nop + bkpt seems to be too specific to be some 
random padding after a bx.

What's your preference here? Either way they look like testisms. I 
checked and adding .arch does not break the arm-none-eabi tests. Not 
checked any other target yet.

Kind regards,
Andre