This is the mail archive of the
mailing list for the elfutils project.
Re: [PATCH] eblopenback: Warn when unable to find ebl backend
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 25 Nov 2015 21:43:25 +0100
- Subject: Re: [PATCH] eblopenback: Warn when unable to find ebl backend
On Wed, 2015-11-25 at 20:03 +0100, Ben Gamari wrote:
> Josh Stone <email@example.com> writes:
> > On 11/25/2015 04:45 AM, Ben Gamari wrote:
> >> This could have easily saved me three hours.
Urgh, that is terrible. I am really sorry about this.
We really should do a better job. One of the problems is that libebl is
kind of setup to never fail, so there is no error reporting. We might
want to reconsider that. For those functions that really need a backend
available to return meaningful results they should probably fail hard
when the backend for a particular machine/arch wasn't there.
> > It's not really kosher for a library to dump on stderr. No other part
> > of elfutils does this AFAICS. Maybe some other location needs to return
> > better errors from not having the ebl->dlhandle?
> I can see the argument here.
Yes, could you describe what kind of calls you were doing that made this
> That being said, as a user of libdw I can
> attest that the debug output really could be improved. As things stand it's
> a nightmare trying to figure out precisely where things go off the
> rails, typically requiring one to literally single-step through the
> library in GDB until you are lucky enough to spot the error. I would
> really appreciate some systematic debug output, even if one needs to
> set a special LIBDW_DEBUG environment variable or some such to see it.
> Would a patch introducing the infrastructure necessary for debug output
> (and a rebased version of this patch) be acceptable?
One troublepoint is libdwfl. A lot of the libdwfl (dwarf frontend
library) functions are supposed to make things simpler by trying various
ways to get at an answer. For example finding a symbol through various
symbol tables, possibly in separate files. And of course unwinding can
go wrong in various ways, but libdwfl will try various ways to get some
results by looking for .eh_frame, .debug_frame, initial or fallback ebi
abi unwind, etc. We don't keep around why/what went wrong "couldn't get
backend, found eh_frame, but no matching range, couldn't
find .debug_frame in main ELF, could get .debug_frame in separate .debug
file, but encountered faulty/bad DWARF encoding, etc."
There was a suggestion for improved/stacked errors, but that was never