[Mono-dev] Status of non-full AOT on x86 mac

Zoltan Varga vargaz at gmail.com
Sun Oct 31 12:50:06 EDT 2010


Hi,

  The original patch looked good, so I commited it.

                Zoltan

On Sun, Oct 31, 2010 at 5:35 PM, Brian Luczkiewicz <brian at sooloos.com>wrote:

> I would suggest to fold this into the preexisting section. Does Darwin/x86
>> not define __MACH__?
>>
>
> __MACH__ is an antiquated way to detect an apple machine. Newer code, both
> out in the world and within the mono tree (e.g. mini-x86.h) seems to use
> __APPLE__. Obviously, do what you want here, but that was my line of
> thinking.
>
>
>
>> And are you sure that __native_client_codegen__ on OSX should influence
>> the file name extension for shared libraries?
>
>
> Since __native_client_codegen__ is the only pre-existing case where we do
> aot on x86 mac, I was being extra careful to make sure that when it's
> defined, the pre-existing behavior is unaffected. I'm unsure whether
> __native_client_codegen__ depends on filename extension and am not in a
> position to test it.
>
> If you happen to know better then that condition is unnecessary.
>
>
>  What warnings are you suppressing there? The surrounding archs don't
>> appear to.
>
>
> The debug information size expression (Ldebug_end - Ldebug_begin) causes a
> warning because it's not computable at assembly time since the sections are
> relocatable. This doesn't appear to cause a problem in practice, but it does
> cause a warning message.
>
>
>
>> Same thoughts wrt the extension here.
>
>
> Same response.
>
>
> Is that a typo? The latter part of the #elif would never be true since it
>> is handled in your #if already.
>>
>
> Yes..good catch. The latter part of the #elif should go.
>
>
>
>>
>> Regards,
>> Andreas
>>
>
>
> Given my responses above, let me know what you think and I will prepare an
> updated patch.
>
> Thanks,
>
> Brian
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20101031/aec62c1b/attachment.html 


More information about the Mono-devel-list mailing list