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

[Alan Modra]

On Mon, Nov 18, 2024 at 04:18:11PM +0000, Andre Vieira (lists) wrote:
> 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.

I didn't look into these failures in any detail, nor am I an ARM
expert.  However, I strongly suspect the fails are not just testcase
peculiarities, and the differences in disassembly will be seen on
arm-nacl just when using default (ie. no -m) options on both the
assembler and disassembler.  So I think you should look into why
arm-nacl seems to need info->mach to be set to bfd_mach_arm_unknown.

Perhaps the assumption about build attributes is wrong for arm-nacl,
or perhaps the existing default mach for arm-nacl needs changing
elsewhere.

-- 
Alan Modra