You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I spent a lot of time looking at instruction traces when debugging a baremetal newlib null pointer dereference. Writes to the pointer location look sensible in the instruction trace but a read returns NULL. It turned out that this null pointer dereference happended because a pointer ended up pointing past the end of physical memory.
It would be great if QEMU could cause a trap (maybe ADDRS/ADDRL? or even better a different exception code so we can diagnose it easily) whenever a memory address is read/written that is unmapped. If this will cause issues when running CheriBSD maybe just logging it in the textual trace/stderr would be great. Suggesting to run info mtree would also be nice.
The text was updated successfully, but these errors were encountered:
I spent a lot of time looking at instruction traces when debugging a baremetal newlib null pointer dereference. Writes to the pointer location look sensible in the instruction trace but a read returns NULL. It turned out that this null pointer dereference happended because a pointer ended up pointing past the end of physical memory.
It would be great if QEMU could cause a trap (maybe ADDRS/ADDRL? or even better a different exception code so we can diagnose it easily) whenever a memory address is read/written that is unmapped. If this will cause issues when running CheriBSD maybe just logging it in the textual trace/stderr would be great. Suggesting to run
info mtree
would also be nice.The text was updated successfully, but these errors were encountered: