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

[tromey at sourceware dot org]

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.