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
