[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/22249] objdump --dwarf-start can be very slow
From: |
mark at klomp dot org |
Subject: |
[Bug binutils/22249] objdump --dwarf-start can be very slow |
Date: |
Wed, 11 Oct 2017 12:24:35 +0000 |
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.
- [Bug binutils/22249] objdump --dwarf-start can be very slow, (continued)
- [Bug binutils/22249] objdump --dwarf-start can be very slow, tromey at sourceware dot org, 2017/10/09
- [Bug binutils/22249] objdump --dwarf-start can be very slow, cvs-commit at gcc dot gnu.org, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, nickc at redhat dot com, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, tromey at sourceware dot org, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, nickc at redhat dot com, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, tromey at sourceware dot org, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, nickc at redhat dot com, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, tromey at sourceware dot org, 2017/10/10
- [Bug binutils/22249] objdump --dwarf-start can be very slow, mjw at fedoraproject dot org, 2017/10/11
- [Bug binutils/22249] objdump --dwarf-start can be very slow, mjw at fedoraproject dot org, 2017/10/11
- [Bug binutils/22249] objdump --dwarf-start can be very slow,
mark at klomp dot org <=