Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Initial Mac OSX Support #117

Merged
merged 9 commits into from Feb 7, 2015
Merged

Initial Mac OSX Support #117

merged 9 commits into from Feb 7, 2015

Conversation

kangaroo
Copy link

@kangaroo kangaroo commented Feb 7, 2015

Supports building up the VM, PAL and various components on Mac OSX 10.10
There are some oddities with the Apple assembler not generating short jumps
and not supporting 1 byte relocs.

This is a continuation of #105 since GitHub cannot detect my new squashed commit.

Supports building up the VM, PAL and various components on Mac OSX 10.10
There are some oddities with the Apple assembler not generating short jumps
and not supporting 1 byte relocs.
@kangaroo kangaroo mentioned this pull request Feb 7, 2015
Initially __LINUX__ was defined when building for OSX as well, bringing
in LONGDOUBLE_IS_DOUBLE 1, and some of the local SEH funcations.
Add a __APPLE__ guard around these as well, so they're properly included.
@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

The .byte issue is still present that @janvorli pointed out.

I tried the .macro suggestion, but OS X generated a reloc, and the smallest reloc size they support is 3 bytes. I'm open to discussion other possibilities.

Perhaps its best to let OS X pad the jumps out, and fix the calculation on the patching side?

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

Few details:

  1. You can replace the following
#if defined(__APPLE__)
    static const char * const coreClrDll = "libcoreclr.dylib";
#else
    static const char * const coreClrDll = "libcoreclr.so";
#endif

by

static const char * const coreClrDll = MAKEDLLNAME_A("coreclr");
  1. Could you please rename the arch/i386/context.clang.s to context.S?
  2. What is the reason for using clang instead of llvm? Is only the former defined on Mac? We use llvm at other places.
  3. The non-clang version of DBG_CheckStackAlignment() is now missing the asm prefix before the "VOID". I know it is not being built now, but I'd keep it there.
  4. Something needs to be done about the macro parameters. We cannot just pass the Handler when there should be no handler.

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

I am sorry, github has renamed the clang and llvm in my previous post

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

Regarding the short jump issue, I just got an idea which probably won't change anything, but still is worth trying. Could you please try to replace the labels of the jumps with numeric labels and put the respective numeric label to the place where the jump should land? Maybe from the fact that these are short range labels, the assembler would decide to put in the short versions.
Like this:

PATCH_LABEL JIT_WriteBarrier_PreGrow32_PatchLabel_CardTable_Check
        cmp     byte ptr [rdi + 0F0F0F0F0h], 0FFh
        jne     1f
        REPRET

        nop // padding for alignment of constant
1:
PATCH_LABEL JIT_WriteBarrier_PreGrow32_PatchLabel_CardTable_Update
    UpdateCardTable_PreGrow32:

@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

  1. MAKEDLLNAME_A seems to only be available in the PAL, is it ok to add pal.h to the corerun.cpp? I only ask because so far nothing seems to include pal.h outside the pal.
    2, 3, 4) Fixed in d288813
  2. I'm open to anything, the only reason I was passing it as Handler right now is its completely unused in NESTED_ENTRY

@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

With the short jump issue, numeric lables (or text) are fine for jumping without a reloc, but it goes back to generating the long jumps.

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

Regarding 1), you're right, I've missed the fact that it is in the corerun.cpp. So please leave it as it is.
As for 5), let me try to figure out something over the weekend.

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

Hmm, so it seems to me that maybe we should let the assembler use the long versions and just put in more / less nops for Mac to achieve the proper alignment of the constants in instructions following the PATCH_LABEL,
The 32 bit constants need to be aligned on 4 bytes, the 64 bit constants on 8 bytes, as you have probably expected.

@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

I'm happy to make the change that way. One quick question, the fast write barriers appear to use PATCH_LABEL to find the constants, but JIT_WriteBarrier does not. Can you point me to where its patch offsets are calculated so I can fit it up as well?

@janvorli
Copy link
Member

janvorli commented Feb 7, 2015

This comment at the JIT_WriteBarrier should explain that:

// This is used by the mechanism to hold either the JIT_WriteBarrier_PreGrow 
// or JIT_WriteBarrier_PostGrow code (depending on the state of the GC). It _WILL_
// change at runtime as the GC changes. Initially it should simply be a copy of the 
// larger of the two functions (JIT_WriteBarrier_PostGrow) to ensure we have created
// enough space to copy that code in.

Currently it is a copy of the JIT_WriteBarrier_PreGrow64, so if you make changes to JIT_WriteBarrier_PreGrow64, you should make the same ones to the JIT_WriteBarrier.

@jkotas
Copy link
Member

jkotas commented Feb 7, 2015

The write barriers are the most performance sensitive helpers. It would be really nice to keep them on the short jump plan, so that they are as small as possible. I think that the jumps emitted via hardcoded bytes is the best solution - as it is right now - is the best solution among the ones discussed.

#determine nproc in a platform independent way
NPROCS=1
OS=`uname`

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be needed anymore

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 854c2ae

@jkotas
Copy link
Member

jkotas commented Feb 7, 2015

LGTM, modulo the feedback above

@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

I believe that addresses everything (again 👍)

Would you like me to squash again, or is it ok as is?

@jkotas
Copy link
Member

jkotas commented Feb 7, 2015

LGTM

jkotas added a commit that referenced this pull request Feb 7, 2015
@jkotas jkotas merged commit bb38f10 into dotnet:master Feb 7, 2015
@jkotas
Copy link
Member

jkotas commented Feb 7, 2015

Thanks a lot!

@kangaroo
Copy link
Author

kangaroo commented Feb 7, 2015

My pleasure, thanks for the quick merge and review.

On to fixing more tests now 👍

@kangaroo kangaroo deleted the osx branch February 7, 2015 04:02
@janvorli
Copy link
Member

janvorli commented Feb 9, 2015

@kangaroo I got one idea about the assembler on clang complaining about the missing macro parameters. Could you please try to add "=" to the Handler parameter to indicate the parameter has a default value that is empty as follows:
.macro NESTED_ENTRY Name, Section, Handler=
and see if that allows omitting the parameter when using the macro?
Clang on my Ubuntu accepts that syntax, so I hope this could work on OSX as well.

@kangaroo
Copy link
Author

kangaroo commented Feb 9, 2015

Nope:

/var/folders/_s/vb2gh7xn20l2wrvvlrf7mpd80000gn/T/virtualcallstubamd64-dd3c5b.s:281:41: error: macro argument 'Handler' is missing
NESTED_ENTRY ResolveWorkerAsmStub, _TEXT

@janvorli
Copy link
Member

janvorli commented Feb 9, 2015

Ok, thanks for testing it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants