Patch for DejaGnu test case "pointers"

[Orjan Friberg <orjan.friberg@axis.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 11365 bytes --]

Hi,

I'm working at Axis Communications in Lund, Sweden, and I'm updating our
port of gdb for cross-debugging. An assign.future has been submitted
previously that covers all employees. This is my first patch submission
(more patches are on the way), so I'd appreciate feedback if any changes
are needed.

I'd like to submit a patch for the DejaGnu test case called pointers. In
pointers.c, the following variables are declared:

float F, *pF;
double D, *pD;

and later the following statements:

F = 1.25E10;
pF = &F;
D = -1.375E-123;
pD = &D;

-1.375E-123 will only fit if a double is (at least) 8 bytes. For a
4-byte double, an underflow occurs. In pointers.exp, there is a test
that prints *pD which fails. However, assigning D something that fits is
not enough since the pattern matching with respect to the decimals for
doubles and floats differ, which also seems to stem from an assumption
about their respective sizes. print *pD is required to match *exactly*,
whereas print *pF is checked only until the first decimal.

I'm not an expert on various sizes of floats and doubles, so maybe I'm
also making assumptions about sizes. From K&R, The C Programming
Language, Appendix B11, "acceptable minimum" for FLT_MIN is 1E-37. I
suggest using D = -1.25E-37, and checking only the first decimal. The
patches below to that.

*************** int more_code()
*** 194,200 ****
      L = -234;
      UL = 234;
      F = 1.25E10;
!     D = -1.375E-123;
      pC = &C;
      ppC = &pC;
      pppC = &ppC;
--- 194,200 ----
      L = -234;
      UL = 234;
      F = 1.25E10;
!     D = -1.25E-37;
      pC = &C;
      ppC = &pC;
      pppC = &ppC;


*************** gdb_expect {
*** 522,528 ****
  
  send_gdb "print *pD\n"
  gdb_expect {
!     -re ".\[0-9\]* = -1.375e-123.*$gdb_prompt $" {
          pass "print value of *pD"
        }
      -re ".*$gdb_prompt $" { fail "print value of *pD" }
--- 522,528 ----
  
  send_gdb "print *pD\n"
  gdb_expect {
!     -re ".\[0-9\]* = -1.2\[0-9\]*e\\-37.*$gdb_prompt $" {
          pass "print value of *pD"
        }
      -re ".*$gdb_prompt $" { fail "print value of *pD" }



Orjan Friberg
Axis Communications AB
E-mail: orjan.friberg@axis.com 
Phone:  +46 46 272 17 68
From hp@axis.com Thu Sep 07 07:38:00 2000
From: Hans-Peter Nilsson <hp@axis.com>
To: orjanf@axis.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch for DejaGnu test case "pointers"
Date: Thu, 07 Sep 2000 07:38:00 -0000
Message-id: <200009071435.QAA17036@ignucius.axis.se>
References: <39B7A02B.EEB3F889@axis.com>
X-SW-Source: 2000-09/msg00059.html
Content-length: 575

> Date: Thu, 07 Sep 2000 16:03:23 +0200
> From: Orjan Friberg <orjanf@axis.com>

> This is my first patch submission
> (more patches are on the way), so I'd appreciate feedback if any changes
> are needed.

Du glömde changelog-entries, som för övrigt ska skickas som
klartext, inte patch. M-x add-change-log-entry i emacs
underlättar.  Annars är det OK till formen; patchen saknar dock
de två första raderna av någon anledning.

Se "Submitting Patches" i URL:en jag skickade tidigare,
<URL: http://gcc.gnu.org/contribute.html >.  Se även andras
patch-mail.

mvh H-P
From hp@axis.com Thu Sep 07 07:41:00 2000
From: Hans-Peter Nilsson <hp@axis.com>
To: gdb-patches@sourceware.cygnus.com
Cc: orjanf@axis.com
Subject: Re: Patch for DejaGnu test case "pointers"
Date: Thu, 07 Sep 2000 07:41:00 -0000
Message-id: <200009071440.QAA17075@ignucius.axis.se>
References: <39B7A02B.EEB3F889@axis.com>
X-SW-Source: 2000-09/msg00060.html
Content-length: 434

> Date: Thu, 07 Sep 2000 16:03:23 +0200
> From: Orjan Friberg <orjanf@axis.com>

> This is my first patch submission
> (more patches are on the way), so I'd appreciate feedback if any changes
> are needed.

Oops, sorry, CC:ed gdb-patches by mistake.  I was helping my
colleague with some slight omissions in his painful(?) first
patch.  The contents of my mail is probably mostly obvious even
though it was in Swedish :-)

brgds, H-P
From orjan.friberg@axis.com Thu Sep 07 08:16:00 2000
From: Orjan Friberg <orjan.friberg@axis.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch for DejaGnu test case "pointers"
Date: Thu, 07 Sep 2000 08:16:00 -0000
Message-id: <39B7B0B4.A53B598E@axis.com>
References: <200009071440.QAA17075@ignucius.axis.se>
X-SW-Source: 2000-09/msg00061.html
Content-length: 878

Hans-Peter Nilsson wrote:
> 
> > Date: Thu, 07 Sep 2000 16:03:23 +0200
> > From: Orjan Friberg <orjanf@axis.com>
> 
> > This is my first patch submission
> > (more patches are on the way), so I'd appreciate feedback if any changes
> > are needed.
> 
> Oops, sorry, CC:ed gdb-patches by mistake.  I was helping my
> colleague with some slight omissions in his painful(?) first
> patch.  The contents of my mail is probably mostly obvious even
> though it was in Swedish :-)
> 
> brgds, H-P

Here is the ChangeLog entry (thanks H-P):

2000-09-07  Orjan Friberg  <orjan.friberg@axis.com>

        * gdb.base/pointers.c: Do not rely on a double being 8 bytes
when
        assigning a small value	to it.
        * gdb.base/pointers.exp: Relax pattern matching of a double's
decimals.

-- 
Orjan Friberg
Axis Communications AB
E-mail: orjan.friberg@axis.com 
Phone:  +46 46 272 17 68
From jtc@redback.com Thu Sep 07 11:45:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC]: Remote Protocol "attach" command.
Date: Thu, 07 Sep 2000 11:45:00 -0000
Message-id: <5mem2wqbwi.fsf@jtc.redback.com>
References: <39AD801B.2C7C@redhat.com>
X-SW-Source: 2000-09/msg00062.html
Content-length: 2646

>>>>> "Michael" == Michael Snyder <msnyder@redhat.com> writes:
Michael> More and more embedded operating systems are multi-process
Michael> these days, and so there exists a need to have a stub or a
Michael> gdbserver already running (perhaps all the time), and have it
Michael> "attach" to another running process and debug it.  For native
Michael> Unix systems, this has traditionally been done by running 
Michael> gdbserver from a shell, giving it the path to the executable,
Michael> and letting it fork the new process.

Michael> I'd like to start a discussion about adding a new remote
Michael> protocol command with which GDB could ask the remote stub
Michael> to attach to a running process (by pid), or possibly to
Michael> open a file and fork a process (by filename/path).  Of course,
Michael> stubs that can't do that would simply return an empty reply
Michael> as always, indicating non-compliance.

I'm not opposed to this, although there appear to be some issues to be
worked out.

At present, when `target remote <foo>' is issued, GDB attaches to and
stops the target, possibly getting thread and section relocation info
in the process.  It would be easier if the `target remote <foo>' only
established communication to a target, and that a separate 'run' or
'attach' command needed to be issued to interact.  This model works
quite well, I use it in my vxWorks/WDB back end.  But I can't see how
it can be retrofited into the remote protocol.  It pretty much assumes
an interrupt driven debug agent that can handle async commands without
disturbing the target system.  I'm afraid I have more questions than 
answers here.

For the command itself, I think it probably should be defined as a
some command letter plus an 'target specific' identifier.  On UNIX
like systems, process-ids are natural.  But on others, a process or
task name may be more appropriate.

As you know, the remote debug protocol has not supported well defined
error codes.  A failure would return EXX, but there was no definition
of the different XX values.  I think that all new commands should do
so.  I'm kicking myself for not doing so when I proposed the breakpoint
extensions a year+ ago.

There already is a detach command.  I think the protocol spec could be
worded to indicate that the program under debug is released to
continue executing.  It does not appear that gdbserver understands the
command.  Question: after the inferior is detached, should you be able
to re-attach (or attach to a different process) without
re-establishing communication to the debug agent (with `target remote
<foo>')?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kevinb@cygnus.com Thu Sep 07 12:37:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFC] Protoize i386mach-nat.c, i960-tdep.c
Date: Thu, 07 Sep 2000 12:37:00 -0000
Message-id: <1000907193655.ZM26339@ocotillo.lan>
References: <1000905232022.ZM22471@ocotillo.lan> <kevinb@cygnus.com>
X-SW-Source: 2000-09/msg00063.html
Content-length: 208

On Sep 5,  4:20pm, Kevin Buettner wrote:

> 	* i386mach-nat.c (fetch_inferior_registers, fetch_core_registers):
> 	Protoize.
> 	* i960-tdep.c (i960_skip_prologue, leafproc_return, mem): Protoize.

Committed.
From kevinb@cygnus.com Thu Sep 07 12:38:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFC] Protoize infptrace.c, infttrace.c
Date: Thu, 07 Sep 2000 12:38:00 -0000
Message-id: <1000907193843.ZM26345@ocotillo.lan>
X-SW-Source: 2000-09/msg00064.html
Content-length: 2141

More protoization...

	* infptrace.c, infttrace.c (child_xfer_memory): Protoize.

Index: infptrace.c
===================================================================
RCS file: /cvs/src/src/gdb/infptrace.c,v
retrieving revision 1.5
diff -u -r1.5 infptrace.c
--- infptrace.c	2000/07/30 01:48:25	1.5
+++ infptrace.c	2000/09/07 19:34:28
@@ -502,7 +502,7 @@
 
 /* Copy LEN bytes to or from inferior's memory starting at MEMADDR
    to debugger memory starting at MYADDR.   Copy to inferior if
-   WRITE is nonzero.
+   WRITE is nonzero.  TARGET is ignored.
 
    Returns the length copied, which is either the LEN argument or zero.
    This xfer function does not do partial moves, since child_ops
@@ -510,12 +510,8 @@
    anyway.  */
 
 int
-child_xfer_memory (memaddr, myaddr, len, write, target)
-     CORE_ADDR memaddr;
-     char *myaddr;
-     int len;
-     int write;
-     struct target_ops *target;	/* ignored */
+child_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write,
+		   struct target_ops *target)
 {
   register int i;
   /* Round starting address down to longword boundary.  */
Index: infttrace.c
===================================================================
RCS file: /cvs/src/src/gdb/infttrace.c,v
retrieving revision 1.3
diff -u -r1.3 infttrace.c
--- infttrace.c	2000/07/30 01:48:25	1.3
+++ infttrace.c	2000/09/07 19:34:31
@@ -4907,7 +4907,7 @@
 
 /* Copy LEN bytes to or from inferior's memory starting at MEMADDR
    to debugger memory starting at MYADDR.   Copy to inferior if
-   WRITE is nonzero.
+   WRITE is nonzero.  TARGET is ignored.
 
    Returns the length copied, which is either the LEN argument or zero.
    This xfer function does not do partial moves, since child_ops
@@ -4915,12 +4915,8 @@
    anyway.  */
 
 int
-child_xfer_memory (memaddr, myaddr, len, write, target)
-     CORE_ADDR memaddr;
-     char *myaddr;
-     int len;
-     int write;
-     struct target_ops *target;	/* ignored */
+child_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write,
+		   struct target_ops *target)
 {
   register int i;
   /* Round starting address down to longword boundary.  */