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 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 > 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, . Se även andras patch-mail. mvh H-P From hp@axis.com Thu Sep 07 07:41:00 2000 From: Hans-Peter Nilsson 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 > 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 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 > > > 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 * 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 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 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 ' 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 ' 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 ')? --jtc -- J.T. Conklin RedBack Networks From kevinb@cygnus.com Thu Sep 07 12:37:00 2000 From: Kevin Buettner 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> 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 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. */