clrmd: Unable to analyze 4GB dumps of 32-bit processes

It seems ClrMD is not able to process 32-bit memory dumps larger than 2GB due to inconsistent address conversion between coreclr and ClrMD.

As @leculver and @mikem8361 already discussed in #280, using ulong types for address values may lead to unexpected behavior on particular platforms.

For your information, I am developing for Tizen wearable devices which run 32-bit (armel) .NET processes on 64-bit Linux kernels. Unlike normal 32-bit processes on other platforms, each user process has 4GB of address space.

As far as I can see in the DAC implementation of coreclr, most of exposed address values are in CLRDATA_ADDRESS types, so we can safely assume them as sign-extended according to this comment. When the values are passed to ClrMD however, they are (implicitly) converted into ulong type (instead of long) which seems not correct for negative CLRDATA_ADDRESS’es.

For example, when the DAC calls into ClrMD using DataTargetAdapter::ReadVirtual() and the value of address is larger than 0x7FFFFFFF (let’s say 0xFFCCBBAA), the ulong value passed to DacDataTargetWrapper appears to be super larger than expected (0xFFFFFFFFFFCCBBAA).

https://github.com/dotnet/runtime/blob/master/src/coreclr/src/debug/daccess/datatargetadapter.cpp#L186-L196

Is this conversion intentional (should I assume sign-extension for ulong)? Or am I missing something?

In my experiment, my sample code (just printing a managed stakctrace) simply worked by modifying the implementation of TO_CDADDR macro in the coreclr runtime. I don’t think this would be a right choice however. Changing all occurrences of ulong in the DAC interfaces of ClrMD to long also looks bad since we will need a lot of work to be done and additional maths in the code.