[Bug runtime/4593] New: kread() functions should provide better error messages

[Bug runtime/4593] New: kread() functions should provide better error messages

[fche at redhat dot com]

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.

-- 
           Summary: kread() functions should provide better error messages
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=4593

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4593] kread() functions should provide better error messages

[joshua dot i dot stone at intel dot com]

------- Additional Comments From joshua dot i dot stone at intel dot com  2007-06-07 01:09 -------
(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.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4593

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4593] kread() functions should provide better error messages

[roland at gnu dot org]

------- Additional Comments From roland at gnu dot org  2007-06-07 01:14 -------
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).

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4593

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug runtime/4593] kread() functions should provide better error messages

[joshua dot i dot stone at intel dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|systemtap at sources dot    |joshua dot i dot stone at
                   |redhat dot com              |intel dot com
             Status|NEW                         |ASSIGNED


http://sourceware.org/bugzilla/show_bug.cgi?id=4593

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.