Re: [PATCH 0/4] Improve elfutils diagnostics

[Frank Ch. Eigler <fche at redhat dot com>]

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