[cfe-dev] Block introspection and GNU runtime new ABI support

[Blaine Garst]

We will likely initially focus on providing introspection data on the  
captured variables rather than the parameters to the block.  Both are  
of interest but with captured variable knowledge we can avoid  
generating copy helper functions for almost all cases.

The reserved field in the block descriptor is the slot I intend to use  
for captured variable knowledge.

Changing the ABI is very painful - we were unable to move the invoke  
function into the descriptor structure as we had originally intended  
for example, so I also advise caution.

Blaine

On Sep 10, 2009, at 12:59 PM, David Chisnall wrote:

> Hi Chris,
>
> On 10 Sep 2009, at 20:54, Chris Lattner wrote:
>
>> On Sep 9, 2009, at 6:39 PM, David Chisnall wrote:
>>
>>> The other patch adds a -fblock-introspection flag.  When this is  
>>> specified, or when -fgnu-runtime is specified, an extra field is  
>>> added to the block structure that contains an Objective-C type  
>>> encoding of the block function.  I've also updated one of the  
>>> block tests to ensure that this field is only being emitted when  
>>> the flag is provided.
>>
>> Hi David,
>>
>> Adding introspection information for blocks is something we'll  
>> probably want to do in the next abi as well, but we'll do it a  
>> different way.  Are you sure you want to diverge on this?
>
> It's a feature we want now, so if you'll let us know how you want to  
> implement it then we can modify our runtime to simplify the  
> compiler, but it is something that we want sooner rather than later  
> (as I said when you originally announced blocks, ideally we'd also  
> like full reflection in bound variables as we have with LanguageKit  
> blocks, but that's probably more effort to implement than it's worth  
> for the few cases where it's useful, and we're reasonably happy to  
> just use Smalltalk for them).
>
> We've only just released the updated runtime for testing, so nothing  
> in the new ABI is set in stone yet - but we would like it to be  
> relatively soon.
>
> David