add ARM IBL sentinel support

[derekbruening]

The current ARM IBL does not support sentinel wrapping. That is (presumably at least) why we see these:

<CURIOSITY : (0) && "fragment_add_ibl_target unknown reason" in file /home/derek/dr/git/src/core/fragment.c line 4375

This covers adding sentinel support.

[zhoubot]

I've got the same problem when implementing the aarch64 version. I'm running the linux.signal tests with timer on. As far as I know, it is caused by unlinking indirect branches when the DR signal handler records the app's pending signal.

For the unlinking, it patches the ibl table offset with unlinked entry core/arch/arm/emit_utils.c#L551 It then directs to the dispatch and the fragment_add_ibl_target asserts the curiosity problem since the fragment table gets a hit.

Is it appropriate to add a check here so that it bypass the assertion? core/fragment.c#L4296

[egrimley]

I'd also like to understand better why DR does this unlinking of fragments in response to a signal. This is a shared code cache, I think, so unlinking a fragment causes a flurry of inter-core memory traffic, while other cores may or may not stumble across the unlinked fragment, depending on how quickly their caches get updated. Since some signals (precise exceptions) have to be dealt with immediately, why not deal with all of them immediately? I suppose what I'd like to see is a 5/10-paragraph overview of how DR handles signals. Perhaps there already is such a thing...

[derekbruening]

Since some signals (precise exceptions) have to be dealt with immediately, why not deal with all of them immediately?

Because asynchronous signals can arrive at arbitrary locations that are difficult to translate back to app state.

See my PhD thesis section 5.3.5.

[derekbruening]

Is it appropriate to add a check here

There's not already one? If not then yes.