Fix debugger attach+read on Linux 32 bit - #45506
Conversation
|
Tagging subscribers to this area: @tommcdon Issue Details
|
janvorli
left a comment
janvorli
left a comment
There was a problem hiding this comment.
LGTM, thank you! Can you please add description and the issue closing reference for the 44745?
|
Will do, and will need to backport. I just need to do some more testing. |
|
// Auto-generated message 69e114c which was merged 12/7 removed the intermediate src/coreclr/src/ folder. This PR needs to be updated as it touches files in that directory which causes conflicts. To update your commits you can use this bash script: https://gist.github.com/ViktorHofer/6d24f62abdcddb518b4966ead5ef3783. Feel free to use the comment section of the gist to improve the script for others. |
cdda3dc to
002e7d1
Compare
|
/backport to release/5.0 |
|
Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/412433334 |
ghost
locked as resolved and limited conversation to collaborators
4 participants
The debug PAL was undefining of macros that cause 32 bit POSIX syscalls to use 64 bit offsets. The offsets are defined in a signed manner, which means that any address over the 2GB range that we use will result in an incoherent call to
preadand similar APIs. This has been the case for years, but it only affected ARM32 systems as they are currently our only Unix 32 bit target. Customers started reporting issues where the debugger wouldn't attach. This happened as we changed the debugger startup path to use symbol exports in CoreCLR for our single file story, meaning that the DAC no longer used a compile time header but an export read that caused to read on the >2GB region of the process when run in a device with enough memory available.