This is the mail archive of the 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

Mark Wielaard <> writes:

> On Wed, 2015-11-25 at 20:03 +0100, Ben Gamari wrote:
>> Josh Stone <> 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

>>  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
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:
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


- Ben

Attachment: signature.asc
Description: PGP signature

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