[Bug binutils/22249] objdump --dwarf-start can be very slow

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=22249

--- Comment #13 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Tom Tromey from comment #4)
> (In reply to Nick Clifton from comment #2)
> >   * For completeness sake if nothing else, shouldn't we also be able to
> > specify an end address for CU dumping ?
> 
> There are really two cases here.
> 
> One is dumping the CU headers but no DIEs.  That's --dwarf-depth=0.
> In this case you want to dump everything.

IMHO it is totally confusing that printing CU headers or not is specified with
--dwarf-depth=0. Why isn't this a separate option?

> The other is expanding some DIE.  In this case, --dwarf-depth=N
> --dwarf-start=DIE is used;
> the printing stops when the next DIE to be printed would have
> a depth below N.  You can see this in action with the Emacs mode -- if it
> did not stop, you'd get the whole CU inserted when expanding a "...".

This seems somewhat user unfriendly.
How is one supposed to pick the "correct" N?
In the case that --dwarf-start=DIE is given, but --dwarf-depth=N is not,
it really should default to --dwarf-depth=DIE-depth. Otherwise you just
keep dumping completely unrelated DIEs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.