From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: Guy Harris <guy@netapp.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to let Alpha debuggers debug a remote target over Telnet
Date: Tue, 25 Apr 2000 20:20:00 -0000
Message-id: <39066032.1E980CE4@cygnus.com>
References: <200004260208.TAA16542@tooting>
X-SW-Source: 2000-04/msg00464.html

Guy Harris wrote:
> 
> > What about ser-pipe.c?
> 
> We're not using it (we're using GDB 4.18 here, so we don't even have
> it), but if, as I infer, it's another alternative to directly
> communicating with the remote over a serial line, yes, it presumably
> should be supported whenever a serial line is supported, just as
> "ser-tcp.c" should.

(I'm now slightly confused. You have been trying this with the current
sources?)

ser-pipe implements a pipe based interface vis:

	target remote |program to run

that program can be anything that talks remote protocol on
stdin/stdout.  The program might be a simulator or some ICE driver.

	Andrew
>From kevinb@cygnus.com Tue Apr 25 20:42:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] step-test.exp changes for IA-64
Date: Tue, 25 Apr 2000 20:42:00 -0000
Message-id: <1000426034223.ZM12414@ocotillo.lan>
X-SW-Source: 2000-04/msg00465.html
Content-length: 2350

I request approval for committing the changes below.

On IA-64, when using "finish" to step out of a function, gdb will stop
on the line containing the call to the function that you've just
stepped out of.  The reason for this is that immediately after the
call instruction is an instruction which restores the global pointer. 
Since this is part of the sequence of instructions forming the call,
it makes sense that gdb would place you on the line of the call instead
of the next executable line after the call.

To further illustrate what's going on, here's a typical call sequence
which shows the saving of the global pointer, the call itself, and the
restoration of the global pointer:

    0x40000000000007d1 <main+113>:              mov r34=r1
    0x40000000000007d2 <main+114>:
                    br.call.sptk.many b0=0x4000000000000870 <foo>;;
    0x40000000000007e0 <main+128>:  [MII]       mov r1=r34

The general register r1 is the global pointer (which is a base
register off of which various data may be found for a particular load
module).  The final instruction moves the saved value in r34 to r1.

	* gdb.base/step-test.exp: On IA-64 targets, when stepping out of
	a call, do not require that gdb stop on the line after the call. 
	Instead, it is permissible for gdb to stop on the line of the
	call itself.

Index: testsuite/gdb.base/step-test.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/step-test.exp,v
retrieving revision 1.1.1.7
diff -u -p -r1.1.1.7 step-test.exp
--- step-test.exp	2000/02/05 07:30:00	1.1.1.7
+++ step-test.exp	2000/04/26 03:11:43
@@ -76,7 +76,7 @@ gdb_test "step" ".*${decimal}.*myglob.*"
 # call?
 
 # On PA64 we end up at a different instruction than PA32
-if { [istarget "hppa2.0w-hp-hpux*"] } {
+if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"]} {
     send_gdb "finish\n"
     gdb_expect {
         -re ".*${decimal}.*a.*5.*= a.*3.*$gdb_prompt $" { pass "step out 1" }
@@ -172,7 +172,7 @@ gdb_expect {
   }
   -re ".*${decimal}.*callee.*STEPI.*$gdb_prompt $" {
     # On PA64 we end up at a different instruction than PA32
-    if { [istarget "hppa2.0w-hp-hpux*"] } {
+    if { [istarget "hppa2.0w-hp-hpux*"] || [istarget "ia64-*-*"] } {
         pass "stepi: finish call 2"
     } else {
 	fail "stepi: finish call 2"