This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Regression: Re: [PATCH 2/6] Code cleanup: dwarf2read.c: Eliminate ::file_write


On Mon, 19 Jun 2017 14:06:53 +0200, Yao Qi wrote:
> Do you have some examples or bugs?  GDB performance improvement is one
> of my todo, so if you have some examples, or bugs, that would be quite
> helpful.

Any backtraces take up to a minute.  That is because GDB expands only whole
CUs (and not specific DIEs) and one CU can be pretty huge in C++ programs,
moreover GDB has to expand tens of CUs to expand just one CU due to some
interdependencies between CUs enforced by dwarf2read.c.  Less serious but
another existing problem may be that dwz DW_TAG_imported_unit is implemented
only in DWARF reader and not in inferior symbol/type system of GDB, therefore
all DW_TAG_imported_unit units get duplicated/multiplicated inside GDB, being
expanded each time again.

Occasional print of an expression takes a minute which may be due to:
	gdb's performance is so terrible that it is unusable
	https://bugzilla.redhat.com/show_bug.cgi?id=1401091

Then conditions of breakpoints get evaluated by GDB and not in inferior which
is commonly unusable to wait for hours until the wished even happens and one
has to rather put an "if" statement into a recompiled debuggee.

Then there is the inability of execute C++ statements which should get fixed
by the 'compile' project but then it will be at least 2 times slower than
needed due to the use of gcc instead of clang.


Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]