Conversation
There was a problem hiding this comment.
Offset is not used, instead MC API will create/insert label to the code directly. But I'd like to keep this on purpose in case we need offset information later. The same thing applies to the following APIs.
|
The corresponding RyuJit change is -- dotnet/coreclr#2868 |
|
LGTM. Is it the case that callers should always invoke these methods in a particular sequence eg: start, blob, [blob,] end? It would be nice to add checks for this but it doesn't look like there is any convenient place to record a bit of state. |
|
That's right although such assertion is done in CoreRT or LLVM backend. |
|
Updated the code to consume cfi.h from CoreCLR. |
lib/ObjWriter/objwriter.cpp
Outdated
There was a problem hiding this comment.
So is the idea here that CoreRT will do something like:
EmitCFIStart(ow, ...);
uint8_t *cfiBlob = ...; uint32_t cfiBlobSize = ...;
for (int offset = 0; offset < cfiBlobSize; offset += ?) {
EmitCFIBlock(ow, &cfiBlob[offset]);
}
EmitCFIEnd(ow);
There was a problem hiding this comment.
Here is full code for it -- dotnet/corert#752
There was a problem hiding this comment.
I might call this "EmitCFICode" instead of "EmitCFIBlob", then. IMO "EmitCFIBlob" implies that this function may process multiple CFI instructions.
There was a problem hiding this comment.
Makes sense. Will update it.
This adds the following CFI unwind emission. EmitCFIStart EmitCFIEnd EmitCFICode The first two sets the range of the code that the frame covers. The last one should be invoked for each offset of the code, if any. The blob data format is shared by the one RyuJit layouts.
4 participants
This adds the following CFI unwind emission.
EmitCFIStart
EmitCFIEnd
EmitCFIBlob
The first two sets the range of the code that the frame covers.
The last one should be invoked for each offset of the code, if any.
The blob data format is shared by the one RyuJit layouts.