This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
Wasm is trying to test for a null on the ldfld at offset 1, and that's causing it to set up a landing pad and make a call to the EH iterator setup. The first sequence point for this method is at offset 36, so when its processing offset 1, there is no debug location set yet. This is problem for llvm as if the function has a debug location, and this one does (it gets set on offset 36), then any call that could be in-lined must have a debug location and this is a problem for the call to initialise the EH info enumerator.
One fix for this particular instance, and at least some of the others that are occurring, could be to not do the null check on the instance ldfld as this is an instance method, so unless this is a reflection call, then the instance should have been checked for null before calling the method.
Another option to fix this problem in general could be to just take the first sequence point and apply that to call to InitFromEhInfo. This is what I've done in the prolog if a call to a class constructor occurs. Would that be the right thing to do? Just asking in case I'm missing something better/obvious.
I'm trying to get source line debugging working again as it broke when we upgraded to LLVM 8 some time back.
With this IL:
Wasm is trying to test for a null on the
ldfld
at offset 1, and that's causing it to set up a landing pad and make a call to the EH iterator setup. The first sequence point for this method is at offset 36, so when its processing offset 1, there is no debug location set yet. This is problem for llvm as if the function has a debug location, and this one does (it gets set on offset 36), then any call that could be in-lined must have a debug location and this is a problem for the call to initialise the EH info enumerator.One fix for this particular instance, and at least some of the others that are occurring, could be to not do the null check on the instance ldfld as this is an instance method, so unless this is a reflection call, then the instance should have been checked for null before calling the method.
Another option to fix this problem in general could be to just take the first sequence point and apply that to call to
InitFromEhInfo
. This is what I've done in the prolog if a call to a class constructor occurs. Would that be the right thing to do? Just asking in case I'm missing something better/obvious.Thanks