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

Blaine Garst blaine at apple.com
Tue Nov 17 12:32:25 PST 2009


Fariborz, Daniel,

If the feature remains as initially described, that is, that when 1<<30 is marked in the flags field that an extra field shows up in the block itself containing the @encode of the block arguments for the gnu runtime, then I have no objection.

The direction is to put not only the block argument @encode description in place but also a concise block layout description such that the runtime can do all the of the copying work without helpers - except for the cases where C++ c/dtors need to be called.  The layout will likely need to serve some new purposes or need to be flexible to serve new purposes in the future.  The descriptor block is where this data will live since it is sharable and immutable.

I forget whether the GNU runtime @encode data is different than ours and so I don't know whether the GNU runtime will be able to use our data or at least wherever our slot does show up and how we mark it, but I think that is a not unreasonable goal to consider.

Blaine



On Nov 17, 2009, at 9:07 AM, Fariborz Jahanian wrote:

> 
> On Nov 17, 2009, at 8:34 AM, David Chisnall wrote:
> 
>> On 18 Sep 2009, at 16:20, Fariborz Jahanian wrote:
>> 
>>> On Sep 18, 2009, at 3:53 AM, David Chisnall wrote:
>>> 
>>>> It hasn't gone in yet.  I've modified my local copy to set flag
>>>> 1<<30 on blocks that have this metadata attached to them, but I was
>>>> waiting for confirmation that this wouldn't break anything for Apple
>>>> before I committed it.
>>>> 
>>> 
>>> gcc uses BLOCK_HAS_DESCRIPTOR =    (1 << 29) as the last used flag.
>>> However, runtime may have different ideas for
>>> (1 << 30). So, answer should come from them.
>> 
>> 
>> I've had this sitting in my local copy for two months now and not  
>> heard any objections to using this flag.  If there are any, please  
>> speak now before I commit...
> 
> I sent a 2nd email to them. Waiting for the response. You can always  
> check it in. We can remove it if they raise objections.
> 
> - fariborz
> 
>> 
>> 
>> David
>> 
>> -- Sent from my PDP-11
>> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev





More information about the cfe-dev mailing list