https://sourceware.org/bugzilla/show_bug.cgi?id=22249
--- Comment #4 from Tom Tromey <tromey at sourceware dot org> --- (In reply to Nick Clifton from comment #2) > * According to the documentation the --dwarf-start=N command line option > (which sets the dwarf_start_die variable) specifies the *number* of the DIE > at which output should start, not the starting address referenced by the > DIE. > > I think that this may be a mistake in the documentation however, as this > does not appear to match the behaviour of the code. It is, because the intent (I added this feature initially) was to pass in the DIE offset -- I suppose I used the term "number" because DIEs are always referred to by offset, so I didn't consider any possible confusion here. > fault. Ie I think that the author's intention was that --dwarf-start would > specify a starting depth for DIE printing No, that's definitely not what I intended. > * 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. 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 "...". FWIW I've sent this and other fixes to the list. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils