[K42-discussion] Cause of cxa_atexit/dso_handle reference

[Donour Sizemore]

So which option would people like to persue; removing static global 
objects from k42 or adding our on definitions of cxa_atexit and dso_handle?

The latter seems more reasonable to me. Am I correct and believing that 
the only issue taken with my previous patch is that their were two 
copies of the definition. I'm sure I could prepare a single version that 
is linked into to both kernel and userspace code.

donour


Patrick G. Bridges wrote:
> No thoughts on this?
> 
> -Patrick
> 
> On Aug 16, 2006, at 12:17 PM, Patrick G. Bridges wrote:
> 
>> On Aug 15, 2006, at 3:25 PM, Bryan S Rosenburg wrote:
>>
>>>
>>> Patrick Bridges wrote on 08/15/2006 05:14:02 PM:
>>>> So, should we just break down and put together simple implemetations
>>>> of cxa_atexit and dso_handle, or should we further limit the
>>> kinds of
>>>> things we do in C++ to avoid these problems (i.e., either forbid
>>>> destructors in certain classes or forbid global objects of certain
>>>> types)?
>>> I'm in favor of forbidding global objects of certain types, if we
>>> can make that work.  We've tried to avoid global objects in
>>> general, and the closer we can keep to that standard, the better.
>>>
>>> Patrick, thanks for looking into this issue so thoroughly.
>> My feeling would be to go ahead and support cxa_atexit and global
>> objects since, unlike exceptions and rtti for example, it should be
>> relatively straightforward. It'll also make porting easier since we
>> won't have to continually hack around these problems on a case-by-
>> case basis.
>>
>> If we don't want to, any suggestion on how to fix this particular
>> case? Can we simply allocate "theDeletedObject" at runtime by new(),
>> or if not new, by casting a static buffer to the appropriate type? I
>> guess part of my problem is that I don't yet understand exactly how
>> it's used and integrates with the fslib stuff.
>>
>>
>> _______________________________________________
>> K42-discussion mailing list
>> K42-discussion at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/k42-discussion
> 
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion