Why does casting a function generate a run-time abort?

[Ziemowit Laski]

On 18 Jun 2004, at 14.39, Richard Henderson wrote:

> On Fri, Jun 18, 2004 at 02:13:11PM -0700, Ziemowit Laski wrote:
>> Yes, I think that what you suggest could work, albeit at the cost of
>> having to add additional machinery to GIMPLE.
>
> Not so much as you'd think, I'll warrent.  In addition, you may be
> able to devirtualize some calls entirely.

Not in ObjC you won't. :-)  The implementation to be called may change 
from underneath you at run-time, as shared libraries are loaded in.

>
>>     {
>>       extern foo_id objc_msgSend(foo_id, char *, blort, blort);
>>       obj0 = objc_msgSend (obj0, "foo message", foo, bar);
>>     }
>
> No.
>
>>     {
>>       extern foo_id __objc_msgSend_local_nnnn(foo_id, char *, blort,
>> blort) asm("objc_msgSend");
>>       obj0 = __objc_msgSend_local_nnnn (obj0, "foo message", foo, 
>> bar);
>>     }
>
> No.

Why not?

>
> How about
>
> 	<CALL_EXPR <METHOD_EXPR obj0 message> (obj0, "message", foo, bar)>
> 	
> perhaps rendered in the pretty printer as
>
> 	obj0 = METHOD<obj0, message>(obj0, "message", foo, bar)
>
> wherein METHOD_EXPR has type "foo_id ()(foo_id, const char *, blort, 
> blort)"
> and expands (during rtl) to objc_msgSend.

Of course, you do realize that objc_msgSend is not the only entry point 
we'd
need to handle in this fashion?  Do you want to have a different 
METHOD_EXPR
for each of them (and for new entry points that the GNU and/or NexT 
runtimes
may throw your way in the future)?

Perhaps a more generic solution would involve a CAST_CALL_EXPR, where 
one
of the arguments is the function to be called (objc_msgSend in our 
example),
and another the signature to use for this particular call.  Still 
redundant
(at least of ObjC), but at least more sane. :-)

>
> I think you definitely want to NOT think about things you could sort-of
> represent with C.

Why not?  I think you absolutely _do_ want to do this, for it guarantees
that ObjC is as portable as the C language underneath it.

> nt to think about how this might be used in C++ and Java before
> settling the semantics of METHOD_EXPR, but I think something like this
> could work well.

Perhaps for Java or C++, where I suspect you're losing semantic 
information
during gimplification.  But in ObjC, you'll just be adding redundant 
means
to express things.

--Zem