arm/thumb: problems with function pointers

arm/thumb: problems with function pointers

[Adrian von Bidder]

Heyho!

When I do something simple like
 == first file ==
int callee() { return 42; }
int main() {
    return caller(callee);
}
 == second file ==
int caller(int (*fn)()) {
    (fn)();
}
 == end ==

and compile this for arm with -mthumb and -fpic (without -fpic I get a
linking error 'bad reloc type 10' so I didn't investigate further), the
pointer to callee does not have its lsb set. Since thumb creates a
_call_via_rX which uses the bx instruction, callee is called in arm
state.

I first had callee in a third file so when compiling main callee would
be undefined, but having callee together with main does not make a
difference.

Tools: as always. gcc-3.0.3/binutils-2.11.2 for production, but I made a
quick experiment with cvs head (14h old) and afaict it's not been fixed
there.

I discovered the problem while trying to get a thumbified busybox. any
help would be appreciated - I suspect it's similar to the fix [1] Phil
Blundell sent me on a similar problem, but it's apparently different
enough to need a different fix. (no English teacher reading this?
good... ;-) 

My bet is that what was done to be R_ARM_ABS32 in elf32-arm.h needs to
be done to R_ARM_GOT32 relocations, too. But the R_ARM_GOT32 case is
more complex than the ABS32 one...

Hmmm, I'll probably look at it tomorrow - but I don't know nuffin about
bfd, so I'd be glad if somebody else is quicker.
 
greets from Zürich
-- vbi

[1] 'Re: Linking arm thumb code' from 23 Nov 2001 10:24:39 +0000

Re: arm/thumb: problems with function pointers

[Phil Blundell]

On Wed, 2002-01-16 at 16:37, Adrian von Bidder wrote:
> My bet is that what was done to be R_ARM_ABS32 in elf32-arm.h needs to
> be done to R_ARM_GOT32 relocations, too. 

Mmm, yeah, probably.  Well, try this.

p.

Index: elf32-arm.h
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.h,v
retrieving revision 1.62
diff -u -r1.62 elf32-arm.h
--- elf32-arm.h	2001/10/12 11:16:21	1.62
+++ elf32-arm.h	2002/01/16 17:58:32
@@ -1585,6 +1588,8 @@
 		off &= ~1;
 	      else
 		{
+		  if (sym_flags == STT_ARM_TFUNC)
+		    value |= 1;
 		  bfd_put_32 (output_bfd, value, sgot->contents + off);
 		  h->got.offset |= 1;
 		}

Re: arm/thumb: problems with function pointers

[Adrian von Bidder]

On Wed, 2002-01-16 at 18:59, Phil Blundell wrote:
> On Wed, 2002-01-16 at 16:37, Adrian von Bidder wrote:
> > My bet is that what was done to be R_ARM_ABS32 in elf32-arm.h needs to
> > be done to R_ARM_GOT32 relocations, too. 
> 
> Mmm, yeah, probably.  Well, try this.

The fix works if the symbol in question is a global symbol, not if it's
a local symbol.

So, we now have special handling in R_ARM_ABS32 and two cases of
R_ARM_GOT32. It makes me wonder if we are not just fighting symptoms of
an error further down - shouldn't the relocation entries be generated
with the lsb set in the first place, instead of setting the bit only on
final link, as it appears is what we do now?

the output of readelf for the .rel.text section has 'symbol values' for
thumb symbols without the lsb set - isn't that the place where it should
already be set? Q: who generates .rel.text section in object files?

What I mean: readelf says
Relocation section '.rel.text' at offset ...:
  Offset    Info  Type          Symbol's Value Symbol's Name
  00000014  0071a R_ARM_GOT32         00000004 callee  

Symbol table '.symtab' contains 10 entries:
      Num:    Value  Size Type    Bind   Vis      Ndx Name
     7: 00000004     4 THUMB_FUNC GLOBAL DEFAULT    1 callee

(similar for LOCAL symbol callee). Shouldn't 'Symbol's Value' in
.rel.texst be 0005 and not 004 right from the start (or do I
misunderstand what the value means?)

greets from Zürich
-- vbi

Re: arm/thumb: problems with function pointers

[Phil Blundell]

On Thu, 2002-01-17 at 10:14, Adrian von Bidder wrote:
> the output of readelf for the .rel.text section has 'symbol values' for
> thumb symbols without the lsb set - isn't that the place where it should
> already be set? Q: who generates .rel.text section in object files?
> 
> What I mean: readelf says
> Relocation section '.rel.text' at offset ...:
>   Offset    Info  Type          Symbol's Value Symbol's Name
>   00000014  0071a R_ARM_GOT32         00000004 callee  

I don't really understand what you're getting at here.  At the time the
relocation is generated there isn't (in the general case) any way to
know whether the target is a Thumb function.  That information is only
available for certain at the time the relocation is being resolved,
during final link.  GOT entries for locally-defined symbols are a rather
special case.

It _is_ true that elf32_arm_final_link_relocate looks like a bit of a
mess, and there might be some opportunity for refactoring to make it
simpler.

p.

Re: arm/thumb: problems with function pointers

[Adrian von Bidder]

On Thu, 2002-01-17 at 12:44, Phil Blundell wrote:

> I don't really understand what you're getting at here.  At the time the
> relocation is generated there isn't (in the general case) any way to
> know whether the target is a Thumb function.  That information is only
> available for certain at the time the relocation is being resolved,
> during final link.  GOT entries for locally-defined symbols are a rather
> special case.

Ok, my fault - I was only looking at this local symbol and forgetting
that this isn't the normal case.

greets from Zürich
-- vbi