Mark Wielaard mjw@redhat.com writes:
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.
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 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?
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 LD_LIBRARY_PATH :(.
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 libelf.'
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 breakpoint spots.
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/
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 facility.
Cheers,
- Ben