Re: [Pyobjc-dev] Re: libffi

[Jack J. <Jac...@cw...>]

On Monday, Nov 11, 2002, at 13:10 Europe/Amsterdam, Ronald Oussoren 
wrote:
>> And if that doesn't work we should try to fix darwin_closure.S. 
>> Without known any PowerPC assembler (i.e. this paragraph should be 
>> considered as near-zero-content:-) my first guess is that the jump 
>> table at .L60 is the problem. Either the table itself (although the 
>> .L44-.L60 form of the entries should have removed any relocation) or 
>> the loading of its address, a few lines above. Examining how the C 
>> compiler creates code for switch statements if -dynamic is in effect 
>> should give us a clue.
> Fixing darwin_closure.S might be usefull anyway. If anyone want to 
> show of their PPC assembly skills: here's your change. I've posted a 
> question about this on the libffi mailinglist, but that seems to be 
> dead. I suppose the developers migrated to the gcc related 
> mailinglists.

A further experiment indicates that the problem is probably the loading 
of the base address of the jump table. If I compile a switch statement 
with "cc -static" the base address is loaded with a code sequence 
similar to the one in darwin_closure.S:
	lis r9,ha16(L10)
	la r0,lo16(L10)(r9)
If I compile with cc -dynamic (or plain cc, apparently -dynamic is 
default?) I get a sequence I don't fully understand,
but the key bit seems to be
	bcl 20,31,L1$pb
L1$pb:
	mflr r10
      ....
	addis r9,r10,ha16(L10-L1$pb)
	la r9,lo16(L10-L1$pb)(r9)
so it seems they're using some sort of a relative subroutine jump to 
get the address of L1$pb into r10, and subsequently address relative to 
that to get rid of relocation. I've attached the code in case someone 
wants to have a look.