[cfe-commits] patch: libcxxabi cxa_*_virtual and cxa_guard_* methods

[Nick Lewycky]

On 22 May 2011 13:52, John McCall <rjmccall at apple.com> wrote:

>
> On May 22, 2011, at 1:45 PM, Nick Lewycky wrote:
>
> On 22 May 2011 12:23, Howard Hinnant <hhinnant at apple.com> wrote:
>
>> On May 20, 2011, at 2:11 AM, Nick Lewycky wrote:
>>
>> > I've started dipping my toes in the libcxxabi project by implementing a
>> few simple methods. Patch attached, please review!
>> >
>> > This isn't heavily tested, I'm mostly just trying to make sure I have
>> the style down. Please let me know if we should be using different file
>> names (hard to follow a pattern where there isn't one), of if the private
>> methods in cxa_guard actually belong in an anonymous namespace, etc.
>> >
>> > Nick
>> >
>> > <libcxxabi-virtual-and-guard.patch>
>>
>> I disagree with John that your implementation doesn't support the
>> recursive calls for *different* static objects.  I believe it does.
>
>
> Thanks. I was just about to write up an email to the same effect. It does
> support recursive calls for different static objects because the lock it
> uses is the second byte of the guard variable, not a global (or per-thread)
> lock.
>
>
> Yeah, sorry about that.
>
> Back when I thought that we needed to support self-recursive
> initialization, I came up with a way to do this. The fundamental problem
> with pthread_self() is that it returns an 8-byte opaque object (ie., they
> aren't guaranteed to be dense), and C++11's thread library is worse. (Linux
> supports "gettid()" which returns a 4-byte ID which would fit neatly in the
> guard variable, but let's leave that aside for the moment.) We can construct
> our own thread ID by creating a thread_local variable, and we can make it
> use only 7 bytes by giving it 256 byte alignment. The recursion depth
> counter would then be kept on the initialization byte (supporting 254 levels
> of recursion depth with values 0 and 1 reserved for an unlocked guard
> variable).
>
>
> This won't work;  the initialization byte has to stay zero until
> initialization is complete.
>

My mistake, of course the ABI document states that the first byte must not
be modified by __cxa_guard_acquire.

(By the way, unless I missed it, the ABI document never says that the guard
variable is initialized to zero. It seems to me that it has to be though...)

NIck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110522/15371235/attachment.html>