public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Keith Seitz <keiths@redhat.com>
To: Roland Schwingel <roland@onevision.com>
Cc: insight@sourceware.org
Subject: Re: [PATCH/gdbtk] Update stackwin gdb api usage
Date: Thu, 24 May 2012 01:12:00 -0000	[thread overview]
Message-ID: <4FBD8AF0.2010009@redhat.com> (raw)
In-Reply-To: <4F79C3F2.3020908@onevision.com>

On 04/02/2012 08:21 AM, Roland Schwingel wrote:
>
> A general question:
> The direction of stack dump in insight is opposite to when issueing a
> backtrace inside gdb itself. Is this on purpose? Wouldn't it be nicer
> when insight's stack window would show the stack in the same order?

Yes, that was a design decision made many, many years ago. I don't have 
a preference to sort the stack "properly." If you find the time to write 
up a patch, I would consider/approve it.

> diff -ruNp gdbtk_orig/generic/gdbtk-stack.c gdbtk/generic/gdbtk-stack.c
> --- gdbtk_orig/generic/gdbtk-stack.c	2012-03-30 09:29:15.000000000 +0200
> +++ gdbtk/generic/gdbtk-stack.c	2012-04-02 16:13:11.351540500 +0200
> @@ -1,5 +1,6 @@
>   /* Tcl/Tk command definitions for Insight - Stack.
> -   Copyright (C) 2001-2012 Free Software Foundation, Inc.
> +   Copyright (C) 2001, 2002, 2003, 2008, 2011
> +   Free Software Foundation, Inc.
>
>      This file is part of GDB.
>

You already did this. :-)

> @@ -26,6 +27,10 @@
>   #include "dictionary.h"
>   #include "varobj.h"
>   #include "arch-utils.h"
> +#include "stack.h"
> +#ifndef PC_SOLIB
> +#include "solib.h"
> +#endif
>
>   #include<tcl.h>
>   #include "gdbtk.h"

I believe the proper etiquette in gdb is to simply include solib.h 
unconditionally. It should not hurt anything. I tested this on mingw32 
and x86_64-linux with no troubles.

> @@ -475,24 +480,24 @@ gdb_stack (ClientData clientData, Tcl_In
>         /* Find the outermost frame */
>         r  = GDB_get_current_frame (&fi);
>         if (r != GDB_OK)
> -	return TCL_ERROR;
> +        return TCL_ERROR;
>
>         while (fi != NULL)
>           {
>             top = fi;
> -	  r = GDB_get_prev_frame (fi,&fi);
> -	  if (r != GDB_OK)
> -	    fi = NULL;
> +          r = GDB_get_prev_frame (fi,&fi);
> +          if (r != GDB_OK)
> +            fi = NULL;
>           }
>
> +      result_ptr->obj_ptr = Tcl_NewListObj (0, NULL);
> +
>         /* top now points to the top (outermost frame) of the
>            stack, so point it to the requested start */
>         start = -start;
> -      r = GDB_find_relative_frame (top,&start,&top);
> -
> -      result_ptr->obj_ptr = Tcl_NewListObj (0, NULL);
> +      r = GDB_find_relative_frame (top,&start,&top);

Weird. My mail agent has removed the spaces after the commas. In the 
patch, all looks well. There does appear to be some whitespace trailing 
the "r = GDB_find_relative_frame (...);" line, though. Please 
double-check and remove if it is actually there. [and not another trick 
of my mail agent]

>         if (r != GDB_OK)
> -	return TCL_OK;
> +        return TCL_OK;
>
>         /* If start != 0, then we have asked to start outputting
>            frames beyond the innermost stack frame */
> @@ -503,8 +508,8 @@ gdb_stack (ClientData clientData, Tcl_In
>               {
>                 get_frame_name (interp, result_ptr->obj_ptr, fi);
>                 r = GDB_get_next_frame (fi,&fi);
> -	      if (r != GDB_OK)
> -		break;
> +              if (r != GDB_OK)
> +               break;

"break;" doesn't appear indented properly, though. Please double-check.

>               }
>           }
>       }

This rest of the whitespace change is okay, but please submit these 
sorts of patches separate from more substantial patches. It is a lot 
easier for me to review without that cluttering up the patch.

> @@ -515,14 +520,14 @@ gdb_stack (ClientData clientData, Tcl_In
>   /* A helper function for get_stack which adds information about
>    * the stack frame FI to the caller's LIST.
>    *
> - * This is stolen from print_frame_info in stack.c.
> + * This is stolen from print_frame_info/print_frame in stack.c.
>    */
> +
>   static void
>   get_frame_name (Tcl_Interp *interp, Tcl_Obj *list, struct frame_info *fi)
>   {
> -  struct symtab_and_line sal;
>     struct symbol *func = NULL;
> -  const char *funname = 0;
> +  const char *funname = NULL;
>     enum language funlang = language_unknown;
>     Tcl_Obj *objv[1];
>
> @@ -532,75 +537,39 @@ get_frame_name (Tcl_Interp *interp, Tcl_
>         Tcl_ListObjAppendElement (interp, list, objv[0]);
>         return;
>       }
> -  if ((get_frame_type (fi) == SIGTRAMP_FRAME))
> +  if (get_frame_type (fi) == SIGTRAMP_FRAME)
>       {
>         objv[0] = Tcl_NewStringObj ("<signal handler called>", -1);
>         Tcl_ListObjAppendElement (interp, list, objv[0]);
>         return;
>       }
> -
> -  sal =
> -    find_pc_line (get_frame_pc (fi),
> -		  get_next_frame (fi) != NULL
> -		&&  !(get_frame_type (fi) == SIGTRAMP_FRAME)
> -		&&  !(get_frame_type (fi) == DUMMY_FRAME));
> -
> -  func = find_pc_function (get_frame_pc (fi));
> -  if (func)
> -    {
> -      struct minimal_symbol *msymbol = lookup_minimal_symbol_by_pc (get_frame_pc (fi));
> -      if (msymbol != NULL
> -	&&  (SYMBOL_VALUE_ADDRESS (msymbol)
> -	>  BLOCK_START (SYMBOL_BLOCK_VALUE (func))))
> -	{
> -	  func = 0;
> -	  funname = GDBTK_SYMBOL_SOURCE_NAME (msymbol);
> -	  funlang = SYMBOL_LANGUAGE (msymbol);
> -	}
> -      else
> -	{
> -	  funname = GDBTK_SYMBOL_SOURCE_NAME (func);
> -	  funlang = SYMBOL_LANGUAGE (func);
> -	}
> -    }
> -  else
> +  if (get_frame_type (fi) == ARCH_FRAME)
>       {
> -      struct minimal_symbol *msymbol = lookup_minimal_symbol_by_pc (get_frame_pc (fi));
> -      if (msymbol != NULL)
> -	{
> -	  funname = GDBTK_SYMBOL_SOURCE_NAME (msymbol);
> -	  funlang = SYMBOL_LANGUAGE (msymbol);
> -	}
> +      objv[0] = Tcl_NewStringObj ("<cross-architecture call>", -1);
> +      Tcl_ListObjAppendElement (interp, list, objv[0]);
> +      return;
>       }
>
> -  if (sal.symtab)
> +  find_frame_funname (fi,&funname,&funlang,&func);

Argh! Darn mail agent! I apologize ahead of time if I ask you to watch 
out for this, and it turns out to be my mail agent and not you.

> +
> +  if (funname)
>       {
>         objv[0] = Tcl_NewStringObj (funname, -1);
>         Tcl_ListObjAppendElement (interp, list, objv[0]);
>       }
>     else
>       {
> -#if 0
> -      /* we have no convenient way to deal with this yet... */
> -      if (fi->pc != sal.pc || !sal.symtab)
> -	{
> -	  deprecated_print_address_numeric (fi->pc, 1, gdb_stdout);
> -	  printf_filtered (" in ");
> -	}
> -      printf_symbol_filtered (gdb_stdout, funname ? funname : "??", funlang,
> -			      DMGL_ANSI);
> -#endif
> -      objv[0] = Tcl_NewStringObj (funname != NULL ? funname : "??", -1);
> +    	char *lib = NULL;

Can you double-check the indent level on the above line? It doesn't look 
right. [Apologies again if my mail agent maligned it.]

> +      objv[0] = Tcl_NewStringObj (funname ? funname : "??", -1);
>   #ifdef PC_SOLIB
> -      if (!funname)
> -	{
> -	  char *lib = PC_SOLIB (get_frame_pc (fi));
> -	  if (lib)
> -	    {
> -	      Tcl_AppendStringsToObj (objv[0], " from ", lib, (char *) NULL);
> -	    }
> -	}
> +      lib = PC_SOLIB (get_frame_pc (fi));
> +#else
> +      lib = solib_name_from_address (get_frame_program_space (fi),
> +        get_frame_pc (fi));

GNU coding standards prefer that "get_frame_pc (fi));" be aligned 
underneath "get_frame_program_space (fi),".

>   #endif

This has nothing to do with your patch other than the fact that you are 
touching this, but could you check the indentation on "#endif" while 
you're touching this code? It looks a little off.

> +      if (lib)
> +        Tcl_AppendStringsToObj (objv[0], " from ", lib, (char *) NULL);
> +
>         Tcl_ListObjAppendElement (interp, list, objv[0]);
>       }
>   }
> diff -ruNp gdbtk_orig/library/stackwin.itb gdbtk/library/stackwin.itb
> --- gdbtk_orig/library/stackwin.itb	2008-02-09 02:23:42.000000000 +0100
> +++ gdbtk/library/stackwin.itb	2012-04-02 09:40:19.507691900 +0200
> @@ -1,5 +1,5 @@
>   # Stack window for Insight.
> -# Copyright (C) 1997, 1998, 1999, 2002, 2003, 2008 Red Hat
> +# Copyright (C) 1997-2012 Red Hat, Inc.
>   #
>   # This program is free software; you can redistribute it and/or modify it
>   # under the terms of the GNU General Public License (GPL) as published by
> @@ -68,20 +68,14 @@ itcl::body StackWin::update {event} {
>         set frames {}
>       }
>
> +    $itk_component(slb) delete 0 end
>       if {[llength $frames] == 0} {
> -      $itk_component(slb) delete 0 end
>         $itk_component(slb) insert end {NO STACK}
>         return
>       }
>
> -    $itk_component(slb) delete 0 end
>       set levels 0
>       foreach frame $frames {
> -      set len [string length $frame]
> -
> -      if {$len>  $maxwidth} {
> -	set maxwidth $len
> -      }
>         $itk_component(slb) insert end $frame
>         incr levels
>       }
> diff -ruNp gdbtk_orig/library/stackwin.ith gdbtk/library/stackwin.ith
> --- gdbtk_orig/library/stackwin.ith	2005-12-23 19:26:50.000000000 +0100
> +++ gdbtk/library/stackwin.ith	2012-04-02 09:40:23.623824000 +0200
> @@ -1,5 +1,5 @@
>   # Stack window class definition for GDBtk.
> -# Copyright (C) 1997, 1998, 1999 Cygnus Solutions
> +# Copyright (C) 1997-2012 Red Hat, Inc.
>   #
>   # This program is free software; you can redistribute it and/or modify it
>   # under the terms of the GNU General Public License (GPL) as published by
> @@ -20,7 +20,6 @@ itcl::class StackWin {
>     inherit EmbeddedWin GDBWin
>
>     private {
> -    variable maxwidth 40
>       variable Running 0
>       variable protect_me 0
>       method build_win {}
>

Ok with those minor changes.

Thanks!
Keith

  reply	other threads:[~2012-05-24  1:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-02 15:21 Roland Schwingel
2012-05-24  1:12 ` Keith Seitz [this message]
2012-05-25 10:23 Roland Schwingel

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=4FBD8AF0.2010009@redhat.com \
    --to=keiths@redhat.com \
    --cc=insight@sourceware.org \
    --cc=roland@onevision.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).