At the moment, all we get is "pointer dereference failed". We should also see the pointer value, and could enjoy even more information. The present tactic of setting context->last_error to a static unchanged string would have to change. An easy improvement would be to statically allocate an new error_buffer string field in the context, which embedded-C code could sprintf into and incidentally use to set the context->last_error.
(In reply to comment #0) > At the moment, all we get is "pointer dereference failed". > We should also see the pointer value, and could enjoy even > more information. It's not really kread() creating the message, but the other convenience macro CATCH_DEREF_FAULT(). The problem is that the underlying deref() macros use a goto for error handling, so I can only have a single catch-point per function to formulate an error message. So it's often hard to know *which* pointer failed. There are ways to get around that, but I'm not sure how to do it in a generic way. Probably the cleanest way is to fill in the error message right before the goto in deref(). The dwarf accessors also call deref() -- would this change be ok for those as well? > The present tactic of setting context->last_error > to a static unchanged string would have to change. An easy > improvement would be to statically allocate an new error_buffer > string field in the context, which embedded-C code could sprintf > into and incidentally use to set the context->last_error. This is a good idea.
It is entirely possible to change the argument signature of the deref and store_deref macros, and have them do something more sophisticated for error handling. For the loc2c-emitted instances, it would not be hard to pass through a string to be used as an argument that the translators makes up to identify each instance (i.e. which $foo expr or part of one is responsible for the deref).
Fixed committed. The deref macros now output a message formatted like this: snprintf(..., "kernel read fault at 0x%p (%s)", addr, #addr) I didn't change the deref signature, so for now the message just contains whatever bare pointer name was passed in. We can consider improving that later as an enhancement.