[PATCH 0/4] Improve elfutils diagnostics
Frank Ch. Eigler
fche at redhat.com
Wed May 13 17:31:00 UTC 2015
Hi, Mark -
> [...] I am still pondering these two patches. The idea is
> sane. Some operations are compound and a simple error code/string
> only tells you something failed, but not really why or what was
> done. [...]
Yup.
> One implementation detail that I like to see changed is to make the
> details errmsg a list of strings instead of one big string (and
> similarly for dw_tried_paths). [...]
How would such a list-of-strings be represented? Considering that
this is C, and the list arity will vary, we'd be doing dynamic
allocation anyway, right?
> Also I wonder if this is mixing two issues. a) provide more
> information (the tried path/file) when something goes wrong and b)
> providing a "chain of errors" to explain why some call really failed
> when the operation was really a compounded search result. [...]
An error chaining facility would be great, but if each link is permitted
to carry extra text per chain link (file name or operation attempted),
then it can be built -on top of- this scheme, rather than vice versa.
> There is also the detail that not all lookups need to be path/file
> based [...] But the lookups don't need to create the Elf or Dwarf
> from an actual file (name). They can also create them from a file
> descriptor.
If errors in these originate from elfutils code, that code could
accumulate verbose error messages too.
> [...] And I can imagine a find_debuginfo callback that gets
> debuginfo files from some remote server.
If the errors come from outside elfutils code (invoked by a callback),
then perhaps the callbacks could use an elfutils hook to append error
message fragments. (Or the the app could store those errors
out-of-band, and combine it later with the infra-elfutils messages.)
- FChE
More information about the elfutils-devel
mailing list