This is the mail archive of the gdb-patches@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]

Re: gdbtk: Patch for terrible slow stepping


Roland Schwingel wrote:
> 
> Hi....
> 
> I today found this mailing list... I found a bug in gdbtk which made it
> terribly slow using it (especially when running on cygwin).
> I posted this problem 2 days ago to the gdb mailing list. Yesterday I
> was able to fix this problem in my own.
> 
> For details to the problem please look here:
> http://sources.redhat.com/ml/gdb/2003-05/msg00298.html
> 
> I made a patch to gdb/gdbtk/generic/gdbtk-cmds.c (based on current GDB
> current CVS head) which I want to supply here
> now. Maybe someone can check this in, after validation?
> (Btw. the fix description I posted to standard gdb mailinglist yesterday
> was slightly incorrect - sorry, due to technical problems I couldn't
> supply a diff yesterday. The fix here is totally correct - from my point
> of view ;-)
> 
> This fix bypasses unneeded calls to lookup_symtab() which appears to be
> evil slow, at least in many cases.
> 
> Thanks,
> 
> Roland

Hi Roland, 

First and most trivial, the indentation of your patch is all screwy.
You'll have to fix that, according to the GNU coding standard.

With that out of the way, is it really faster to call stat
(which touches the file system) than to call lookup_symtab
(which just grubs thru memory)?  I thought stat was especially
slow on cygwin.  What kind of program are you debugging?
Does it have lots and lots of source files, or something?

Thanks,
Michael

> 
>   -------------------------------------------------------------------------------
> --- gdbtk-cmds.c        2003-05-23 09:02:15.000000000 +0200
> +++ gdbtk-cmds.c.patched        2003-05-23 11:22:29.000000000 +0200
> @@ -35,6 +35,7 @@
>  #include "top.h"
>  #include "annotate.h"
>  #include "block.h"
> +#include "filenames.h"
> 
>  /* tcl header files includes varargs.h unless HAS_STDARG is defined,
>     but gdb uses stdarg.h, so make sure HAS_STDARG is defined.  */
> @@ -1036,7 +1037,7 @@
>                        int objc, Tcl_Obj *CONST objv[])
>  {
>    struct symtab *st;
> -  char *filename, *fullname;
> +  char *filename, *fullname = NULL;
> 
>    if (objc != 2)
>      {
> @@ -1045,20 +1046,36 @@
>      }
> 
>    filename = Tcl_GetStringFromObj (objv[1], NULL);
> -  st = lookup_symtab (filename);
> +
> +  if (IS_ABSOLUTE_PATH (filename))
> +  {
> +        struct stat st;
> +        const int status = stat (filename, &st);
> 
> -  /* We should always get a symtab. */
> -  if (!st)
> +        if (status == 0)
> +        {
> +               if (S_ISREG (st.st_mode))
> +                       fullname = filename;
> +        }
> +  }
> +
> +  if (fullname == NULL)
> +  {
> +       st = lookup_symtab (filename);
> +
> +       /* We should always get a symtab. */
> +       if (!st)
>      {
>        gdbtk_set_result (interp, "File not found in symtab (2)");
>        return TCL_ERROR;
>      }
> 
> -  if (st->fullname == NULL)
> +       if (st->fullname == NULL)
>      fullname = symtab_to_filename (st);
> -  else
> +       else
>      fullname = st->fullname;
> -
> +  }
> +
>    /* We may not be able to open the file (not available). */
>    if (fullname == NULL)
>      {


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