Implement native stack unwinding for Linux

[janvorli]

This change implements native stack unwinding using the libunwind on
Linux. I have also fixed bunch of issues / details in the related code:

1. 0x in front of %p inside format string
2. Subtraction of -1 from dl_info.dli_sname
3. Added .cfi_xxxx annotation to the CallDescrWorkerInternal and the
   LEAF_ENTRY / LEAF_END macros.
4. Changed local labels in the CallDescrWorkerInternal to be prefixed by
   .L to see the CallDescrWorkerInternal in the stack trace
5. Changed moveOWord to use movdqu - it was being called with one of the
   parameters unaligned

[janvorli]

@jkotas Could you please take a look?

[janvorli]

@kangaroo This is what works on Linux with the libunwind from http://www.nongnu.org/libunwind. It seems that what we need to change for OSX is the WinContextToUnwindContext function in seh-unwind.cpp. We should be able to use unw_set_reg on OSX for all registers with the OSX libunwind (provided it works the same way as the libunwind in LLVM), while with the other libunwind, e.g. the RSP is considered read only.

[janvorli]

@kangaroo This unix_issue177 branch is the branch that I've created for you and me to work on the unwinder.

[kangaroo]

@janvorli Awesome! I'll try to take a look tonight. For #5 see: https://github.com/dotnet/coreclr/issues/141

[kangaroo]

Also, what (if any) tests are you validating against right now?

[janvorli]

@kangaroo No tests yet. I've just created a simple C# app that dumps managed stack trace. Like this (needs to be compiled with optimizations off so that the compiler preserves all the methods and the dump doesn't contain just main):

    class Program
    {
        static void A()
        {
            B();
        }

        static void B()
        {
            C();
        }

        static void C()
        {
            D();
        }

        static void D()
        {
            Console.WriteLine(System.Environment.StackTrace);
        }

        static void Main(string[] args)
        {
            A();
        }
    }

[jkotas]

Maybe call it PAL_VirtualUnwind to make it clear that it is not a regular Win32 API?

[janvorli]

Makes sense

[kangaroo]

I'll try to address my review comments with a patch after dinner.

[kangaroo]

Initial PR to clean up OS X here: #284

It still needs a bit of work, since its not actually displaying the stack trace yet, but it doesn't break build or crash anymore.

[janvorli]

@kangaroo

This API also isn't available on mac. From the lower context it looks like we're trying to see a register spill to a stack slot, and ensure we load from there instead.

Shouldn't unw_get_reg take care of this internally?

GC currently relies on having these context pointers so that when it moves an object to which a register stored somewhere on the stack points, it can update the value of the register on the stack. So what we are trying to do there is to get a pointer to the stack location that we can keep and GC can update it later.
The fact that we cannot get the pointers using the API provided by the libunwind on OSX will require some likely nontrivial changes in the coreclr. We have already discussed it a bit with @jkotas some time ago when I was looking for the libunwind to use on Linux.
One option we have here is to ensure that object pointed to by registers are always pinned. Then the context pointer are unnecessary. It is not clear to me though what exactly needs to be done to do that.
Now that I am thinking about it, I actually wonder if we really need the context pointers for the native frames. @jkotas, do you know if there is a case where a pointer to an object managed by GC would be stored in a register stored in one of the native frames?

[kangaroo]

@dotnet-bot test this please

[jkotas]

do you know if there is a case where a pointer to an object managed by GC would be stored in a register stored in one of the native frames

Yes, pointer to an object managed by GC would be stored in a register stored in one of the native frames.

One option we have here is to ensure that object pointed to by registers are always pinned

If the unwind on Mac does not support context pointers, I would not worry about it right now. It will become a problem only once we start enabling GC - I would do it as part of enabling GC.

It is not clear to me though what exactly needs to be done to do that.

It would require: keeping track of unavailable register context pointers in REGDISPLAY - it may be as simple as storing NULL as register context pointer when it is not available, and then using that information to pin the values that cannot be updated in EECodeManager::EnumGcRefs.

[janvorli]

@jkotas I've reflected your feedback in cf3213d, could you take a look please?

[janvorli]

@kangaroo Our changes are now in the master branch.

[kangaroo]

@janvorli excellent, I've been looking at the existing machinery around exception handling expecting thats up next ;)

[janvorli]

@kangaroo Regarding the exception handling. I've started to work on a plan for it and I've figured that most of the stuff in PAL like the PAL_TryExcept and all the related stuff will go away. Only the exception raising stuff will stay (RtlpRaiseException, SEHRaiseException, RaiseException). We will use plain C++ exceptions instead of this low level simulation of SEH. So hopefully there should be no platform specific stuff for that.
There will be changes needed in the coreclr itself though.

[pgavlin]

@janvorli Do you have a timeline for the PAL changes?

[kangaroo]

@janvorli Yes, a lot of the existing stuff looked overly complicated. I think C++ exceptions are the right way to go.

[AndyAyersMS]

@janvorli can you keep us informed as the EH plans evolve?

[janvorli]

@pgavlin @AndyAyersMS @kangaroo Let's move further discussion to #192 which @sergiy-k has created for the exception handling work.

[janvorli]

@pgavlin I have already made the changes in PAL and the related PAL_TRY, PAL_EXCEPT, ... macros locally and I'd like to send out a PR for these today.

[janvorli]

@AndyAyersMS I hope I'll be able to share all the plan details tomorrow.