Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
  • * Re: RFA: Deprecate remote protocol sequence-ID
       [not found] <38DAF122.3CA0E862@cygnus.com>
       [not found] ` <38DB0EE5.831CD611@ozemail.com.au>
@ 2000-03-24 14:02 ` J.T. Conklin
  2000-04-01  0:00   ` J.T. Conklin
  1 sibling, 1 reply; 3+ messages in thread
From: J.T. Conklin @ 2000-03-24 14:02 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: GDB Patches

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I'd like to put forward the proposal that the sequence-id:
Andrew> $sequence-id:packet-data#checksum
Andrew>
Andrew> be clearly deprecated.  GDB doesn't produce them and all known targets
Andrew> do nothing useful with them.  Further, the syntax is dangerous as it
Andrew> restricts (in a very bizare way) the contents of actual packets.

I agree that we can mark it deprecated, but I'm not sure doing so
affords us any more freedom wrt. packet contents.  There are deployed
debug stubs which can not be updated that will interpret packets with
buf[2] == ':' as having a sequence numbers.  We've been able to avoid
such packets so far, is it really that onerous of a restriction?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Fri Mar 24 14:04:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFA: Deprecate remote protocol sequence-ID
Date: Fri, 24 Mar 2000 14:04:00 -0000
Message-id: <5mhfdwvxcu.fsf@jtc.redbacknetworks.com>
References: <38DAF122.3CA0E862@cygnus.com> <38DB0EE5.831CD611@ozemail.com.au> <38DB24AB.7881FFA1@cygnus.com>
X-SW-Source: 2000-03/msg00564.html
Content-length: 275

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I think a simple reliable separate transport layer is needed.  I'd even
Andrew> go as far as a new packet wrapper (replacing $...#NN and +-).

Here, here!

        --jtc

-- 
J.T. Conklin
RedBack Networks
From msnyder@cygnus.com Fri Mar 24 14:05:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: John Wehle <john@feith.com>
Cc: cgf@cygnus.com, nsd@cygnus.com, eliz@delorie.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Fri, 24 Mar 2000 14:05:00 -0000
Message-id: <38DBE6AF.4A7B@cygnus.com>
References: <200003242200.RAA13376@jwlab.FEITH.COM>
X-SW-Source: 2000-03/msg00565.html
Content-length: 4117

John, Eli, Jim et al, 

Nick Duffek also recently did some work related to frameless
function backtraces on the X86.  I don't know whether his 
work is checked into the main trunk.  I'd like to see him
involved in this discussion, so that we don't wind up with
two solutions to the same problem.

				Thanks,
				Michael

John Wehle wrote:
> 
> > Is it possible to tell a bit more about the problem, and how is it
> > solved?
> 
> It's desirable to omit the frame pointer when compiling leaf functions
> when targeting the x86 processor as this provides another hard register
> (%ebp) which can be used by the register allocators.  Using
> -momit-leaf-frame-pointer instructs GCC to compile code in this manner.
> Unfortunately GDB has a rather strong belief that %ebp always points to
> the frame and is unable to locate function arguments or local variables
> when the frame pointer is omitted.  The changes allow GDB to locate the
> frame based on the value in %esp.
> 
> >  Perhaps even a short test case, before and after the change?
> 
> An example is backtracing through sigtramps on Solaris (the Solaris library
> contains functions which don't use %ebp as the frame pointer).  For example
> ... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123
> #7  0x80ffa5b in rl_read_key () at readline.c:578
> 
> The correct backtrace is:
> 
> #0  0x80068745 in _libc_sigprocmask ()
> #1  0x80098763 in sigprocmask ()
> #2  0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156
> #3  0x800685b1 in _sigacthandler ()
> #4  <signal handler called>
> #5  0x800682b8 in _libc_read ()
> #6  0x80098b33 in read ()
> #7  0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123
> #8  0x80ffd8f in rl_read_key () at readline.c:578
> 
> > Also, do the original problems affect Solaris alone, or are they
> > common to all gcc/x86-based architectures?
> 
> They're common to all gcc/x86-based architectures.
> 
> > It's quite difficult to judge a large patch for two different problems
> > without having a more-or-less clear notion of the issues involved.
> 
> Actually they're slight variations of same problem which is how to locate
> the frame.  The GDB patch in question supports locating the frame for x86
> code:
> 
>   1) In a leaf function where the frame pointer has been omitted.  GCC
>      currently supports generating this if -momit-leaf-frame-pointer is
>      specified.  It's desirable to make this the default once debugging
>      support is in place.
> 
>   2) In a function where the frame pointer has been omitted and the stack
>      pointer is unchanging.  For example:
> 
>        int global;
> 
>        void
>        unchanging_sp(int a, int b)
>          {
> 
>          global = a + b;
>          print_global();
>          }
> 
>      I have a patch for GCC to support omitting the frame pointer in this
>      case which has been delayed pending debugger support.  It's desirable
>      to also have this as part of the default x86 code generation strategy.
> 
>   3) In a function where "andl" has been used to align the frame.  I have
>      an experimental patch for GCC to support aligning the frame in this
>      fashion in order to improve x86 floating point performance.
> 
> The original GDB work was done in November 1998 and January 1999.  I'd be
> happy to dust things off on my side in order to get these changes installed
> if you're interested in working with me.  BTW, the necessary paperwork
> is already on file.
> 
> -- John
> -------------------------------------------------------------------------
> |   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
> |    John Wehle    |     Fax: 1-215-540-5495  |                         |
> -------------------------------------------------------------------------
From jtc@redback.com Fri Mar 24 14:24:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: USE_STRUCT_CONVENTION for NetBSD/i386
Date: Fri, 24 Mar 2000 14:24:00 -0000
Message-id: <5md7okvwfx.fsf@jtc.redbacknetworks.com>
References: <5msnxieegg.fsf@jtc.redbacknetworks.com> <38DAD990.D91D6D1B@cygnus.com>
X-SW-Source: 2000-03/msg00566.html
Content-length: 1360

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> ! int
>> ! i386nbsd_use_struct_convention (int gcc_p, struct type *type)
>> ! {
>> !   return !(TYPE_LENGTH (type) == 1
>> !          || TYPE_LENGTH (type) == 2
>> !          || TYPE_LENGTH (type) == 4
>> !          || TYPE_LENGTH (type) == 8);
>> ! }
>> !

Andrew> I'd add a FIXME pointing out known problems with the function. 
Andrew> Otherwize ok.

It's not i386nbsd_use_struct_convention() that needs a FIXME, as it
now properly identifies all functions which return structures via a
hidden pointer vs. those which return structures via registers.  It's
i386_extract_return_type() which doesn't know that structures with a
single float or double field are returned in floating point registers.

Andrew> I assume Mark is trying to figure out why NetBSD can't simply
Andrew> use a common i386_use_struct_convention function.  I take it
Andrew> from your answer, that NetBSD's convention isn't 100% standard
Andrew> (where standard would mean what someone other than Linux or
Andrew> *BSD did.  Solaris/x86?).

I don't think NetBSD does anything non-standard other than defining
DEFAULT_PCC_STRUCT_RETURN to 0 in its gcc config.  So this behavior
should be shared among all x86 targets that do the same: cygwin,
freebsd, linux-aout, and mach.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Fri Mar 24 14:44:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: Re: regerror link error
Date: Fri, 24 Mar 2000 14:44:00 -0000
Message-id: <5m8zz8vviv.fsf@jtc.redbacknetworks.com>
References: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-03/msg00567.html
Content-length: 619

>>>>> "Philippe" == Philippe De Muyter <phdm@macqel.be> writes:
Philippe> makes the compilation of gdb fail on my system (m68k-motorola-sysv) :
Philippe> [...] 

Philippe> Actually, I have found a __regerror, but no regerror.  How
Philippe> can we fix that ?

I think the __regerror() function in gnu-regex.c needs to be renamed
regerror().  All the other functions in that file are defined without
leading double-underscores with a weak_alias() which I assume maps the
two forms together in glibc.  It certainly looks like the underscores
aren't supposed to be there.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From nsd@cygnus.com Fri Mar 24 14:45:00 2000
From: nsd@cygnus.com
To: msnyder@cygnus.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, john@feith.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Fri, 24 Mar 2000 14:45:00 -0000
Message-id: <200003242245.WAA07630@nog.bosbc.com>
References: <38DBE6AF.4A7B@cygnus.com>
X-SW-Source: 2000-03/msg00568.html
Content-length: 780

>Nick Duffek also recently did some work related to frameless
>function backtraces on the X86.

Yup.

>I don't know whether his 
>work is checked into the main trunk.

Nope.  I wanted to tighten up a couple things before committing the
changes.

>I'd like to see him
>involved in this discussion, so that we don't wind up with
>two solutions to the same problem.

Thanks for the heads-up.

>> It's desirable to omit the frame pointer when compiling leaf functions
>> when targeting the x86 processor as this provides another hard register
>> (%ebp) which can be used by the register allocators.

The code I wrote handles non-leaf functions too.  It only works on x86 at
the moment, but I tried to make it architecture-independent.

I'll try to post my patches this weekend.

Nick
From jimb@zwingli.cygnus.com Fri Mar 24 15:26:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: handle sparse register sets in Insight register window
Date: Fri, 24 Mar 2000 15:26:00 -0000
Message-id: <200003242326.SAA17809@zwingli.cygnus.com>
X-SW-Source: 2000-03/msg00569.html
Content-length: 5252

The Insight register window doesn't properly display register sets
that have holes in the register numbering.  Jim Ingham's change of
1999-10-05 doesn't fix the whole problem.


In gdb/gdbtk/generic/ChangeLog-gdbtk:

2000-03-24  Jim Blandy  <jimb@redhat.com>

	Handle the fact that there are holes in the register numbering.
	(gdb_regnames): Return value is now a list of pairs of the form
	{REGNAME NUMBER}.
 	(get_register_name): Record both the register name and number.


In gdb/gdbtk/library/ChangeLog:

2000-03-24  Jim Blandy  <jimb@redhat.com>

	Handle the fact that there are holes in the register numbering.
	* actiondlg.tcl (ActionDlg::constructor): Handle new type of
 	gdb_regnames result.
	* regwin.itb (RegWin::init_reg_display_vars, RegWin::build_win):
 	Same.  Use the register numbers provided by gdb_regnames; don't
	just assume that the Nth element is register N.


Index: gdb/gdbtk/generic/gdbtk-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-cmds.c,v
retrieving revision 1.4
diff -c -r1.4 gdbtk-cmds.c
*** gdb/gdbtk/generic/gdbtk-cmds.c	2000/02/29 22:47:37	1.4
--- gdb/gdbtk/generic/gdbtk-cmds.c	2000/03/24 23:19:55
***************
*** 1834,1840 ****
  }
  
  /* This implements the TCL command `gdb_regnames', which returns a list of
!    all of the register names. */
  
  static int
  gdb_regnames (clientData, interp, objc, objv)
--- 1834,1840 ----
  }
  
  /* This implements the TCL command `gdb_regnames', which returns a list of
!    all of the register names, and their indices. */
  
  static int
  gdb_regnames (clientData, interp, objc, objv)
***************
*** 1854,1861 ****
       int regnum;
       void *argp;		/* Ignored */
  {
!   Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
! 			    Tcl_NewStringObj (REGISTER_NAME (regnum), -1));
  }
  
  /* This implements the tcl command gdb_fetch_registers
--- 1854,1869 ----
       int regnum;
       void *argp;		/* Ignored */
  {
!   /* Build a tuple of the form "{REGNAME NUMBER}", and append it to
!      our result.  */
!   Tcl_Obj *array[2];
!   Tcl_Obj *pair;
! 
!   array[0] = Tcl_NewStringObj (REGISTER_NAME (regnum), -1);
!   array[1] = Tcl_NewIntObj (regnum);
!   pair = Tcl_NewListObj (2, array);
! 
!   Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr, pair);
  }
  
  /* This implements the tcl command gdb_fetch_registers
Index: gdb/gdbtk/library/actiondlg.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/actiondlg.tcl,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 actiondlg.tcl
*** gdb/gdbtk/library/actiondlg.tcl	2000/02/07 00:19:42	1.1.1.1
--- gdb/gdbtk/library/actiondlg.tcl	2000/03/24 23:20:00
***************
*** 30,36 ****
      set top [winfo toplevel [namespace tail $this]]
      wm withdraw $top
  
!     set Registers [gdb_regnames]
      if {$Line != ""} {
        set Locals  [gdb_get_locals "$File:$Line"]
        set Args    [gdb_get_args "$File:$Line"]
--- 30,40 ----
      set top [winfo toplevel [namespace tail $this]]
      wm withdraw $top
  
!     set Registers {}
!     set tmp [gdb_regnames]
!     foreach pair $tmp {
! 	lappend Registers [lindex $pair 0]
!     }
      if {$Line != ""} {
        set Locals  [gdb_get_locals "$File:$Line"]
        set Args    [gdb_get_args "$File:$Line"]
Index: gdb/gdbtk/library/regwin.itb
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/regwin.itb,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 regwin.itb
*** gdb/gdbtk/library/regwin.itb	2000/02/07 00:19:42	1.1.1.1
--- gdb/gdbtk/library/regwin.itb	2000/03/24 23:20:01
***************
*** 77,83 ****
    
    set regMaxLen 0
    foreach r [gdb_regnames] {
!     set l [string length $r]
      if {$l > $regMaxLen} {
        set regMaxLen $l
      }
--- 77,83 ----
    
    set regMaxLen 0
    foreach r [gdb_regnames] {
!     set l [string length [lindex $r 0]]
      if {$l > $regMaxLen} {
        set regMaxLen $l
      }
***************
*** 187,206 ****
    set reg_display_list {}
    set regnames [gdb_regnames]
    set i 1
-   set rn 0
    foreach r $regnames {
!     set reg_display($rn,name) $r
!     set format [pref getd gdb/reg/$r-format]
      if {$format == ""} { set format x }
      set reg_display($rn,format) $format
!     if {$args != "" && [pref getd gdb/reg/$r] == "no"} {
        set reg_display($rn,line) 0
      } else {
        set reg_display($rn,line) $i
        lappend reg_display_list $rn
        incr i
      }
-     incr rn
    }
    set num_regs [expr {$i - 1}]
    set max_regs $rn
--- 187,206 ----
    set reg_display_list {}
    set regnames [gdb_regnames]
    set i 1
    foreach r $regnames {
!     set name [lindex $r 0]
!     set rn [lindex $r 1]
!     set reg_display($rn,name) $name
!     set format [pref getd gdb/reg/$name-format]
      if {$format == ""} { set format x }
      set reg_display($rn,format) $format
!     if {$args != "" && [pref getd gdb/reg/$name] == "no"} {
        set reg_display($rn,line) 0
      } else {
        set reg_display($rn,line) $i
        lappend reg_display_list $rn
        incr i
      }
    }
    set num_regs [expr {$i - 1}]
    set max_regs $rn
From jimb@zwingli.cygnus.com Fri Mar 24 15:45:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: swat a warning in solib.c
Date: Fri, 24 Mar 2000 15:45:00 -0000
Message-id: <npzoro3pba.fsf@zwingli.cygnus.com>
References: <200003240048.QAA20906@cleaver.cygnus.com>
X-SW-Source: 2000-03/msg00570.html
Content-length: 260

> A common trick when using catch_errors is to pass an int argument
> as a void* by casting it.  This generates warnings (if nothing else!)
> when int and void* are not the same size.  Instead let's pass the
> address of the int.

Thanks.  Please commit this.
From john@feith.com Fri Mar 24 15:55:00 2000
From: John Wehle <john@feith.com>
To: nsd@bosbc.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Fri, 24 Mar 2000 15:55:00 -0000
Message-id: <200003242355.SAA14221@jwlab.FEITH.COM>
X-SW-Source: 2000-03/msg00571.html
Content-length: 966

>>> It's desirable to omit the frame pointer when compiling leaf functions
>>> when targeting the x86 processor as this provides another hard register
>>> (%ebp) which can be used by the register allocators.
>
> The code I wrote handles non-leaf functions too.  It only works on x86 at
> the moment, but I tried to make it architecture-independent.

I only handle non-leaf functions if the stack pointer is unchanging (i.e.
there are no arguments placed on the stack of the function being called).
Are you handling non-leaf functions even when the stack pointer is changing?

Does your patch handle functions where the prologue uses "andl" to align
the frame?

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------


^ permalink raw reply	[flat|nested] 3+ messages in thread
    • end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <38DAF122.3CA0E862@cygnus.com>
     [not found] ` <38DB0EE5.831CD611@ozemail.com.au>
     [not found]   ` <38DB24AB.7881FFA1@cygnus.com>
2000-03-24  7:22     ` RFA: Deprecate remote protocol sequence-ID Jim Kingdon
2000-03-24 14:02 ` J.T. Conklin
2000-04-01  0:00   ` J.T. Conklin

    This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox