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

[nickc at redhat dot com]

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi Tom,

  Thanks for suggesting a patch.  There are a couple of potential problems
however:

  * 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.  Either that, or the
documentation is correct and the code is wrong.  From the way that the
documentation is written however, it would appear that the code may be at
fault.  Ie I think that the author's intention was that --dwarf-start would
specify a starting depth for DIE printing and --dwarf-depth would specify a
maximum depth for DIE printing.  If that is correct, then the code needs to be
fixed, and maybe we should consider adding a new option, eg
--dwarf-starting-offset=N to specify the starting address.

  * For completeness sake if nothing else, shouldn't we also be able to specify
an end address for CU dumping ?

  What do you think ?

Cheers
  Nick

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