Update GC heap range in StompWriteBarrier on ARM

[echesakov]

As discovered in #17851 JIT_CheckedWriteBarrier was not properly patched during GCToEEInterface::StompWriteBarrier when operation=WriteBarrierOp::StompResize

As consequence objects in higher generation sometime can miss cards on card table which causes objects in ephemeral ranges (assigned via JIT_CheckedWriteBarrier) be collected. Such situation is described in https://github.com/dotnet/coreclr/issues/17851#issuecomment-391206977

The problem manifest itself as intermittent segfaults in GC or WriteBarrier code and HeapVerify failures when COMPlus_HeapVerify=1. Affects both Windows and Linux.

This PR enables under ARM already implemented for ARM64 mechanism updating g_highest_address g_lowest_address via ::StompWriteBarrierResize. Also found that ::FlushWriteBarrierInstructionCache call is needed right such call (at least for ARM).

Fixes #17851

Tested manually on Ubuntu/arm for more than 10 hours and Windows/arm for couple hours
@janvorli @jkotas PTAL

[echesakov]

@dotnet-bot test Ubuntu x64 Checked Innerloop Build and Test

[CarolEidt]

@echesakovMSFT - I've loosely followed the discussion on #17851, and it seems like there was a lot of background knowledge that you had to acquire in order to track this down. Do you think you'd be able to write up some notes that might make it easier for someone else to track down similar issues in future?

[echesakov]

@CarolEidt Sure, I can try to collect all the ideas in a document somewhere, but I mostly followed the debugging procedure described by @janvorli (thanks a lot for writing this!) in the comments here https://github.com/dotnet/coreclr/issues/15381#issuecomment-377197181 and there https://github.com/dotnet/coreclr/issues/15381#issuecomment-377206297. Also enabling additional stress logging helped a lot.

The main challenge for me was to make LLDB running on Ubuntu/arm, so I can use SOS (and at least be able to do sos DumpLog). I believe this should be definitely documented somewhere (if it's not already).

@tommcdon @mikem8361 Are you familiar with the LLDB issue on Ubuntu/arm (when LLDB is installed from Ubuntu repo) which manifests itself as error: process launch failed: Lost debug server connection.
I found that LLVM_HOST_TRIPLE=arm-linux-gnueabihf must be explicitly passed to cmake when compile arm targeting LLDB. If you want me to document it somewhere what should be appropriate place to do so? I suspect a paragraph in https://github.com/dotnet/coreclr/blob/master/Documentation/building/buildinglldb.md but please confirm? I also have created a Dockerfile cross-compiling arm/LLDB (which is definitely much faster then native compilation on ARM device), but I am not sure if there is a place for this in dotnet/coreclr repo.

/сс @janvorli

[mikem8361]

It would be great if you could add this info to the buildinglldb.md below. I’m currently working on improving our lldb/sos story (better testing across all our distros and platforms, better documentation on how to install or build lldb). I working in a new (currently private) diagnostics<https://github.com/dotnet/diagnostics.git> repo that contains all the SOS related projects. It would be great to share with me your experience on Ubuntu/arm with lldb and SOS. When it comes to lldb or SOS arm, I really don’t have any experience.