This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH 0/4] Improve elfutils diagnostics
- From: Frank Ch. Eigler <fche at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 13 May 2015 13:31:00 -0400
- Subject: Re: [PATCH 0/4] Improve elfutils diagnostics
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. [...]
> 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
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.)