Mark Wielaard <mjw(a)redhat.com> writes:
On Wed, 2015-11-25 at 20:03 +0100, Ben Gamari wrote:
> Josh Stone <jistone(a)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.
It's okay. This sort of thing comes with the territory.
We really should do a better job. One of the problems is that libebl
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
Well, much of the time I spent debugging wasn't even against GHC. I
spent quite a while trying to figure out why `readelf -r` thought all of
my relocations were invalid. Since there was no debug output I had no
choice but to step through the executable in GDB. It took me the better
part of an hour to eventually realize that there was a typo in my
> 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.
Sure, my point here is that even a rather ad-hoc system of "set this
environment variable to activate a slew of fprintfs scattered at common
failure points throughout the codebase" would be sufficient. If you
really wanted to be systematic about it you could make the environment
variable a logging level or bitmask for the various subsystems without
All I want is a way to begin to localize a failure besides
single-stepping through the library. Currently I need to relearn the
structure and implementation of libdw/libdwfl/libelf every time I find a
bug. Thankfully I've been accumulating a list of commonly useful
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
Sure, that would be great! That being said, it's more than is strictly
necessary and I'd hate to see the perfect become the enemy of the good.
I'm asking for more of a debugging facility than an error-reporting