This is the mail archive of the gdb@sources.redhat.com 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]

gdb/Insight 5.3 really slow when stepping - Now solved (fix included)!


Hi. again....

Yesterday I posted the attached problem here. At the same time I started out to
track down the problem on my own. And I think I found it. When using gdbtk
stepping is now as fast as when using commandline gdb or the tui interface.


The problem is IMHO in the gdb_find_file_command() function in
gdb/gdbtk/generic/gdbtk-cmds.c

I am quite unfamiliar with gdb's internals and maybe I have ruined something but maybe not.
I hope this is the right place to publish my fix.


From what I have understood gdb_find_file_command() is used from gdbtk to find the
fullname of a file and check its presence. It is doing this by calling lookup_symtab().
This lookup_symtab() call appears to be that expensive and *terribly* slowed down
operations and causing all these filesystem lookups. (look into my attached previous
posting). I found that I always got an already full qualified filename as argument to
gdb_find_file_command(). So I introduced a shurtcut to check whether the supplied
argument is already fully qualified and when this is the case just check with stat() its
presence. When all this is succesful, the lookup_symtab() call is skipped elsewise
everything goes its regular way.


In code it looks the following (I am referencing current CVS version of this file here):
I first added a
#include "filenames.h"
on line 38.


gdb_find_file_command() starts at line 1035.

There is are 2 lines

filename = Tcl_GetStringFromObj (objv[1], NULL);

st = lookup_symtab (filename);

I added the following code between these 2 lines:
============= snip =================
 /* First check whether the given file is already fully qualified
    and check presence */
 fullname = NULL;
 if (IS_ABSOLUTE_PATH (filename))
 {
      struct stat st;
      const int status = stat (filename, &st);

    if (status == 0)
    {
         if (S_ISREG (st.st_mode))
             fullname = filename;
    }
 }

if (fullname == NULL)
 {
============= snip =================
and a line
}
right after the already mentioned

st = lookup_symtab (filename);

which is at present in line 1048. From now on gdbtk is also really fast..

I hope some maintainers are reading this list and can maybe apply my changes to the CVS, so
that other can also benefit from it. If not maybe someone can give me a hint whom to contact.


Thanks,

Roland
__________________


Hi....


I am using gdb/insight 5.3 on windows (cygwin). And it is *really* slow when stepping...

So I started out to detect where it is slow. Even on stupid lines eg. stepping
thru this block (snipped out of Insight)


- 2370 int    numLines = 0;
2371 NSArray    *predefinedNames;
- 2372 BOOL    mustGenNames = NO;

On every step gdb/insight is doing (in my case) about 17800 (!) filesystem accesses.
I used FileMon from SysInternals. Obviously it checks presence of the source file
and a huge number of headers and other source files. Both system header and selfmade onces.


This makes stepping *really* slow. I encountered that it depends on the file you are
stepping thru in how slow it is.


Is this checking necessary all the time (on every step)? Wouldn't it be enough to scan
all these things just once when entering the file the first time? Can it be switched off?


Thanks for your help,

Roland



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