This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] eblopenback: Warn when unable to find ebl backend


On Wed, 2015-11-25 at 20:03 +0100, Ben Gamari wrote:
> Josh Stone <jistone@redhat.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
really messy?

>  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
finished:
https://bugzilla.redhat.com/show_bug.cgi?id=507682
https://lists.fedorahosted.org/archives/list/elfutils-devel%
40lists.fedorahosted.org/thread/AMF44G66EE4SC7ESV6JTZR4G4FG3HGAS/

Cheers,

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]