Problems with branch-to-arm-from-thumb for typeless symbol

[Hans-Peter Nilsson]

> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Mon, 15 Apr 2013 22:41:51 +0200

> > From: Hans-Peter Nilsson <hp@axis.com>
> > Date: Mon, 8 Apr 2013 13:14:05 +0200
> 
> Ping.

I've decided to drop this patch.

> > > From: Richard Earnshaw <rearnsha@arm.com>
> > > Date: Mon, 8 Apr 2013 12:46:00 +0200
> > 
> > > [sorry for the delayed reply, I've been OoO quite a bit recently]
> > > 
> > > No.
> > > 
> > > The linker should not be inserting code sequences that clobber register 
> > > values when the ABI has not given it explicit permission to do
> > > so.
> > 
> > Wrong, this does not happen.  I can't help but thinking you have
> > misunderstood: no registers are clobbered for veneers from thumb
> > to arm,

(For the original situation as well as for the test-cases, that is.)

> >  which is the issue at hand and what I'm fixing.  Oh, I
> > think I see: the test-case can be confusing but it's the
> > *from-thumb* veneer in the test-cases that is generated with the
> > patch!  (The from-arm veneers are generated anyway even without,
> > due to .thumb_func.)

Still, on re-visiting this, I see the presence and layout of
e.g. elf32_arm_stub_long_branch_v4t_thumb_arm and
elf32_arm_stub_long_branch_any_any (in which pc is clobbered)
and the volatile execution path in arm_type_of_stub
(e.g. elf32_arm_stub_long_branch_v4t_thumb_arm is emitted anyway
for untyped symbols as in the quote) makes it likely that
there's an odd case where restoring the previous behavior
*could* emit a stub where pc is clobbered for some code.

> > 
> > Nick gave his ok, but I'll not act on that until we have
> > consensus.
> > 
> > >  An 
> > > interworking veneer can need that and as such it is incorrect to make 
> > > this change.
> > > 
> > > It might in theory be possible to do this safely when you have the BLX 
> > > <sym> instruction (ARMv5),
> > 
> > There was no BLX in the stubs I observed (because they're
> > default off due to an errata fix and have to be explicitly
> > enabled for v6).
> > 
> > > but that then leads to inconsistency across 
> > > architecture versions and that's equally undesirable.
> > 
> > Again, those mode-switching veneers from thumb to arm (to
> > typeless symbols) already happen when the branch is out of
> > range, so what we have now is inconsistent: the patch *restores*
> > consistency.

In the end, whether that is desirable is up to a maintainer and
there's no consensus.  I've done my part and have no incentive
to introduce the arguably desirable set of warnings or options
for stubs (or no stubs) to typeless symbols.  Distros/packagers
wanting to restore 2.21 behavior can use the patch but should
consider fixing any assembly code where it matters.

> > 
> > Does any of this change your decision?
> > 
> > brgds, H-P
> > 
>