Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: jim.houston@comcast.net
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] thread info - automatic skip frames
Date: Mon, 08 Mar 2004 23:10:00 -0000	[thread overview]
Message-ID: <404CFD46.7010003@redhat.com> (raw)
In-Reply-To: <m3wu5vp5cg.fsf@new.localdomain>

Jim Houston wrote:
> Hi Everyone,
> 
> I developed this patch to support using kgdb on the 
> x86-64 linux kernel.
> 
> The patch adds an option to gdb to skip over boring frames
> in the "thread info" results.  This is useful when most of
> the threads are stopped in the context switch code.  It lets
> you see the frame which shows why the the thread blocked.
> 
> Use:
> 	set skip-frame thread_return,schedule_timeout

Wow -- interesting idea!  I'd like to see some discussion about
the user interface.

I think it's clever to let the user decide what functions
are "un-interesting" -- and if I were the user, I'd probably
think of more un-interesting functions as I went along.
I'd like to be able to add to the list, rather than enter
the whole thing again from scratch.  And that implies a
separate command to clear it.

I also wonder whether the same idea might be useful for
backtrace and "frame".  When I debug, I often have to
go up the stack a ways before finding something interesting.
That can be added separately, but it would be nice to get
the common functionality right from the beginning.

Have you thought about other ways to distinguish "uninteresting"
functions automatically, without imposing on the user to list
them?  Perhaps (under some circumstances, anyway), any function
from a shared library might be uninteresting?  Or any function
lacking debug information?



> 
> --- old/gdb-6.0/gdb/thread.c	2004-01-06 12:34:14.786496352 -0500
> +++ new/gdb-6.0/gdb/thread.c	2004-01-06 12:34:28.804365312 -0500
> @@ -404,6 +404,43 @@
>      }
>  }
>  
> +/*
> + * When using gdb as a kernel debugger, its really boring to
> + * see every thread is blocked in schedule.  By setting a
> + * list of functions with "set skip-frame schedule,thread_return" 
> + * we can display the frame that called into the scheduler.
> + */
> +static char *skip_frame_string;
> +
> +int
> +skip_frame(struct frame_info *fi)
> +{
> +  struct minimal_symbol *msym;
> +  CORE_ADDR pc;
> +  char *name;
> +  char *s, *r;
> +  int n;
> +
> +  pc = get_frame_pc (fi);
> +  msym = lookup_minimal_symbol_by_pc_section(pc, NULL);
> +  if (!msym)
> +    return 0;
> +  name = SYMBOL_LINKAGE_NAME(msym);
> +
> +  for (s = skip_frame_string; s && *s ; ) {
> +    if ((r = strchr(s, ',')))
> +      n = r - s - 1;
> +    else
> +      n = strlen(s);
> +    if (n && strncmp(s, name, n) == 0)
> +      return 1;
> +    if (!r)
> +      break;
> +    s = r + 1;
> +  }
> +  return 0;
> +}
> +
>  /* Print information about currently known threads 
>  
>   * Note: this has the drawback that it _really_ switches
> @@ -416,7 +453,7 @@
>  {
>    struct thread_info *tp;
>    ptid_t current_ptid;
> -  struct frame_info *cur_frame;
> +  struct frame_info *cur_frame, *fi;
>    int saved_frame_level = frame_relative_level (get_selected_frame ());
>    int counter;
>    char *extra_info;
> @@ -448,6 +485,18 @@
>        puts_filtered ("  ");
>  
>        switch_to_thread (tp->ptid);
> +
> +      if (skip_frame_string) {
> +	/* skip up the stack to an interesting frame. */
> +        fi = get_selected_frame ();
> +        while (fi) {
> +          if (!skip_frame(fi))
> +            break;
> +          fi = get_prev_frame(fi);
> +  	  if (fi)
> +            select_frame(fi);
> +        }
> +      }
>        print_stack_frame (get_selected_frame (), -1, 0);
>      }
>  
> @@ -740,4 +789,12 @@
>  
>    if (!xdb_commands)
>      add_com_alias ("t", "thread", class_run, 1);
> +
> +  add_show_from_set (add_set_cmd ("skip-frame", class_obscure,
> +    var_string_noescape, (char *)&skip_frame_string, "\
> +Set list of functions to skip when choosing the frame to display\n\
> +for a info-thread command.  When gdb is used for kernel debug this option\n\
> +allows the frame which calls the scheduler to be displayed rather than\n\
> +having all blocked threads showing the same function in the scheduler.",
> +    &setlist), &showlist);
>  }
> 



WARNING: multiple messages have this Message-ID
From: Michael Snyder <msnyder@redhat.com>
To: jim.houston@comcast.net
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] thread info - automatic skip frames
Date: Fri, 19 Mar 2004 00:09:00 -0000	[thread overview]
Message-ID: <404CFD46.7010003@redhat.com> (raw)
Message-ID: <20040319000900.HIz7DKbzM_jxpyy69pxIMizvf2Dr78tDMxhbNGl4Gg0@z> (raw)
In-Reply-To: <m3wu5vp5cg.fsf@new.localdomain>

Jim Houston wrote:
> Hi Everyone,
> 
> I developed this patch to support using kgdb on the 
> x86-64 linux kernel.
> 
> The patch adds an option to gdb to skip over boring frames
> in the "thread info" results.  This is useful when most of
> the threads are stopped in the context switch code.  It lets
> you see the frame which shows why the the thread blocked.
> 
> Use:
> 	set skip-frame thread_return,schedule_timeout

Wow -- interesting idea!  I'd like to see some discussion about
the user interface.

I think it's clever to let the user decide what functions
are "un-interesting" -- and if I were the user, I'd probably
think of more un-interesting functions as I went along.
I'd like to be able to add to the list, rather than enter
the whole thing again from scratch.  And that implies a
separate command to clear it.

I also wonder whether the same idea might be useful for
backtrace and "frame".  When I debug, I often have to
go up the stack a ways before finding something interesting.
That can be added separately, but it would be nice to get
the common functionality right from the beginning.

Have you thought about other ways to distinguish "uninteresting"
functions automatically, without imposing on the user to list
them?  Perhaps (under some circumstances, anyway), any function
from a shared library might be uninteresting?  Or any function
lacking debug information?



> 
> --- old/gdb-6.0/gdb/thread.c	2004-01-06 12:34:14.786496352 -0500
> +++ new/gdb-6.0/gdb/thread.c	2004-01-06 12:34:28.804365312 -0500
> @@ -404,6 +404,43 @@
>      }
>  }
>  
> +/*
> + * When using gdb as a kernel debugger, its really boring to
> + * see every thread is blocked in schedule.  By setting a
> + * list of functions with "set skip-frame schedule,thread_return" 
> + * we can display the frame that called into the scheduler.
> + */
> +static char *skip_frame_string;
> +
> +int
> +skip_frame(struct frame_info *fi)
> +{
> +  struct minimal_symbol *msym;
> +  CORE_ADDR pc;
> +  char *name;
> +  char *s, *r;
> +  int n;
> +
> +  pc = get_frame_pc (fi);
> +  msym = lookup_minimal_symbol_by_pc_section(pc, NULL);
> +  if (!msym)
> +    return 0;
> +  name = SYMBOL_LINKAGE_NAME(msym);
> +
> +  for (s = skip_frame_string; s && *s ; ) {
> +    if ((r = strchr(s, ',')))
> +      n = r - s - 1;
> +    else
> +      n = strlen(s);
> +    if (n && strncmp(s, name, n) == 0)
> +      return 1;
> +    if (!r)
> +      break;
> +    s = r + 1;
> +  }
> +  return 0;
> +}
> +
>  /* Print information about currently known threads 
>  
>   * Note: this has the drawback that it _really_ switches
> @@ -416,7 +453,7 @@
>  {
>    struct thread_info *tp;
>    ptid_t current_ptid;
> -  struct frame_info *cur_frame;
> +  struct frame_info *cur_frame, *fi;
>    int saved_frame_level = frame_relative_level (get_selected_frame ());
>    int counter;
>    char *extra_info;
> @@ -448,6 +485,18 @@
>        puts_filtered ("  ");
>  
>        switch_to_thread (tp->ptid);
> +
> +      if (skip_frame_string) {
> +	/* skip up the stack to an interesting frame. */
> +        fi = get_selected_frame ();
> +        while (fi) {
> +          if (!skip_frame(fi))
> +            break;
> +          fi = get_prev_frame(fi);
> +  	  if (fi)
> +            select_frame(fi);
> +        }
> +      }
>        print_stack_frame (get_selected_frame (), -1, 0);
>      }
>  
> @@ -740,4 +789,12 @@
>  
>    if (!xdb_commands)
>      add_com_alias ("t", "thread", class_run, 1);
> +
> +  add_show_from_set (add_set_cmd ("skip-frame", class_obscure,
> +    var_string_noescape, (char *)&skip_frame_string, "\
> +Set list of functions to skip when choosing the frame to display\n\
> +for a info-thread command.  When gdb is used for kernel debug this option\n\
> +allows the frame which calls the scheduler to be displayed rather than\n\
> +having all blocked threads showing the same function in the scheduler.",
> +    &setlist), &showlist);
>  }
> 



  reply	other threads:[~2004-03-08 23:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-08 18:23 Jim Houston
2004-03-08 23:10 ` Michael Snyder [this message]
2004-03-09  6:09   ` Eli Zaretskii
2004-03-19  0:09     ` Eli Zaretskii
2004-03-19  0:09   ` Michael Snyder
2004-03-19  0:09 ` Jim Houston
2004-03-19  0:09 ` Andrew Cagney
2004-03-09 20:30   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=404CFD46.7010003@redhat.com \
    --to=msnyder@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jim.houston@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox