[Bug gdb/11316] New: response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[Bug gdb/11316] New: response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[asmwarrior at gmail dot com]

Hello.

I have use two version of gdb under Windows.

http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.1/gdb-7.0.1-mingw32-bin.tar.gz/download
and
http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0.50.20100202/gdb-7.0.50.20100202-mingw32-bin.tar.gz/download

I have found that when I'm debugging a DLL file, in which, I would like to
output the wxString value. So, I use these command ( m_Buffer is a wxString)

output /c m_Buffer.m_pchData[0]@((wxStringData*)m_Buffer.m_pchData - 1)->nDataLength

GDB7.0.1 responses quite fast, but GDB7.0.50 has a noticeable time delay. Is
this a regression. In fact, we have several discussion here in the Codeblocks
forums:

http://forums.codeblocks.org/index.php/topic,11301.msg81615.html#msg81615

By the way, I even build gdb7.0.90 current snapshot myself under Msys system,
but these time lag still exists. Can someone help me? 

Thanks.

-- 
           Summary: response time of output command slows down from gdb
                    7.0.1 to gdb 7.0.50
           Product: gdb
           Version: 7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: asmwarrior at gmail dot com
                CC: gdb-prs at sourceware dot org
 GCC build triplet: Windows
  GCC host triplet: Windows
GCC target triplet: Windows


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11316] response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-02-25 05:30 -------
I personally suspect the change in c_exp.y causes this delay. 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11316] response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-03-24 01:14 -------
Created an attachment (id=4675)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4675&action=view)
profile result of gdb when I'm debugging

Hi, I have done a profile output when using a gdb 7.1 version built with -pg
enabled.

I hope it can help the developers of gdb find the cause of this bug.

Thanks.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11316] response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[swagiaal at redhat dot com]

------- Additional Comments From swagiaal at redhat dot com  2010-04-14 15:16 -------
At first I thought this might be related to
http://sourceware.org/bugzilla/show_bug.cgi?id=11408 but after looking at the
profile results I don't think so any more. Just in case you might want to try
with the version from HEAD. If you are up for it a git bisect will definitely do
the trick here.

Here is the top of the profiling file if anyone else is interested:

Flat profile:



Each sample counts as 0.01 seconds.

  %   cumulative   self              self     total           

 time   seconds   seconds    calls  ms/call  ms/call  name    

 16.97      4.13     4.13 57181341     0.00     0.00  lookup_partial_symbol

 13.50      7.42     3.29 15026121     0.00     0.00  strcmp_iw_ordered

  8.26      9.43     2.01                             lookup_symbol_aux_psymtabs

  2.75     10.10     0.67   712900     0.00     0.00  cpname_parse

  2.73     10.76     0.67  1040866     0.00     0.00  htab_hash_string

  2.63     11.40     0.64                             read_attribute_value

  2.59     12.03     0.63  1233264     0.00     0.00  filename_cmp

  2.55     12.65     0.62                             read_partial_die

  2.07     13.15     0.51 20271728     0.00     0.00  symbol_natural_name

  1.83     13.60     0.45  4080821     0.00     0.00  strcmp_iw

  1.64     14.00     0.40                             load_partial_dies

  1.40     14.34     0.34                             cpname_lex

  1.27     14.65     0.31   459082     0.00     0.00  msymbol_hash_iw

  1.25     14.96     0.30                             d_append_char

  1.19     15.24     0.29   409048     0.00     0.00  hash

  1.11     15.52     0.27  2552245     0.00     0.00  htab_find_slot_with_hash

  1.11     15.79     0.27                             read_attribute

  1.07     16.05     0.26                             d_append_buffer

  1.03     16.30     0.25  1117849     0.00     0.00  bfd_map_over_sections

  1.03     16.55     0.25                             cp_already_canonical

  0.94     16.77     0.23 20271726     0.00     0.00  symbol_search_name

  0.90     17.00     0.22                             htab_mod_1

  0.88     17.21     0.21                             d_print_comp

  0.86     17.42     0.21  5980533     0.00     0.00  bfd_getl32

  0.86     17.63     0.21                             dwarf2_lookup_abbrev

  0.86     17.84     0.21                             isspace

  0.84     18.05     0.20                             qsort_fde_cmp

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11316] response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[asmwarrior at gmail dot com]

------- Additional Comments From asmwarrior at gmail dot com  2010-05-22 01:50 -------
(In reply to comment #3)
> At first I thought this might be related to
> http://sourceware.org/bugzilla/show_bug.cgi?id=11408 but after looking at the
> profile results I don't think so any more. Just in case you might want to try
> with the version from HEAD. If you are up for it a git bisect will definitely do
> the trick here.
> 
> Here is the top of the profiling file if anyone else is interested:
> 
> Flat profile:
> 
> 
> 
> Each sample counts as 0.01 seconds.
> 
>   %   cumulative   self              self     total           
> 
>  time   seconds   seconds    calls  ms/call  ms/call  name    
> 
>  16.97      4.13     4.13 57181341     0.00     0.00  lookup_partial_symbol
> 
>  13.50      7.42     3.29 15026121     0.00     0.00  strcmp_iw_ordered
> 
>   8.26      9.43     2.01                             lookup_symbol_aux_psymtabs
> 
>   2.75     10.10     0.67   712900     0.00     0.00  cpname_parse
> 
>   2.73     10.76     0.67  1040866     0.00     0.00  htab_hash_string
> 
>   2.63     11.40     0.64                             read_attribute_value
> 
>   2.59     12.03     0.63  1233264     0.00     0.00  filename_cmp
> 
>   2.55     12.65     0.62                             read_partial_die
> 
>   2.07     13.15     0.51 20271728     0.00     0.00  symbol_natural_name
> 
>   1.83     13.60     0.45  4080821     0.00     0.00  strcmp_iw
> 
>   1.64     14.00     0.40                             load_partial_dies
> 
>   1.40     14.34     0.34                             cpname_lex
> 
>   1.27     14.65     0.31   459082     0.00     0.00  msymbol_hash_iw
> 
>   1.25     14.96     0.30                             d_append_char
> 
>   1.19     15.24     0.29   409048     0.00     0.00  hash
> 
>   1.11     15.52     0.27  2552245     0.00     0.00  htab_find_slot_with_hash
> 
>   1.11     15.79     0.27                             read_attribute
> 
>   1.07     16.05     0.26                             d_append_buffer
> 
>   1.03     16.30     0.25  1117849     0.00     0.00  bfd_map_over_sections
> 
>   1.03     16.55     0.25                             cp_already_canonical
> 
>   0.94     16.77     0.23 20271726     0.00     0.00  symbol_search_name
> 
>   0.90     17.00     0.22                             htab_mod_1
> 
>   0.88     17.21     0.21                             d_print_comp
> 
>   0.86     17.42     0.21  5980533     0.00     0.00  bfd_getl32
> 
>   0.86     17.63     0.21                             dwarf2_lookup_abbrev
> 
>   0.86     17.84     0.21                             isspace
> 
>   0.84     18.05     0.20                             qsort_fde_cmp


Hi, Thanks for the help.

Today, I downloaded a latest CVS snapshot gdb source code from:
ftp://sourceware.org/pub/gdb/snapshots/current/gdb-7.1.50.20100521.tar.bz2
I just built it under MinGW 4.4.4 and MSYS and link to expat static library.

Then, I test the new generated gdb.exe. Luckily, I found that the response time
to show the wxString value becomes quicker. 

It seems the bug in MinGW gdb 7.0.50 has been fixed. But I'm not sure which
commit has indeed fix the bug.

I will do more test on the new build gdb.exe -7.1.50.20100521

Thanks

asmwarrior (ollydbg from codeblocks' forum)




-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug gdb/11316] response time of output command slows down from gdb 7.0.1 to gdb 7.0.50

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-08-09 16:45 -------
I think this is a dup of 11408.


*** This bug has been marked as a duplicate of 11408 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://sourceware.org/bugzilla/show_bug.cgi?id=11316

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.