Regressions problem (200 failures)

[Donn Terry <donnte@microsoft.com>]

Andrew has asked me to see if there are others affected by this...

On 2/17, the following patch was made to gcc:

> 2000-02-17  Mark Mitchell  <mark@codesourcery.com>
>
>       * function.c (thread_prologue_and_epilogue_insns): Put a line note
>       after the prologue.

It has the effect, in my case at least, of causing gdb to break at the "{"
of many functions when breaking at a function name (5 of 5 main()s that I
tried, but not too many other functions).  (Usually gdb breaks breaks at
the first statement rather than somewhere in the function prologue).
I discussed this with Mark Mitchell, and he concurs that that could be
a side-effect of the patch (whose purpose is to assure that SOME
breakpoint occurs at the beginning of each function).

That, in itself, isn't a problem (except possibly with user perception).
However,
the gdb regressions are written in such a way that they expect to stop at
the
first statement (and often do a single "n", expecting the first statement to
be executed).  This causes well over 200 (mostly cascade) regression
failures.

Andrew asserts that the regressions aren't being too picky in this regard
because
of user expectation.

The problem for me is I suspect that they're BOTH right, but there are
regression
failures unless something happens.

Are there others out there who are seeing this (run the regressions pointing
it at a new gcc)?  (The gcc CVS as of 5:30 or so PST last night still
exhibited the
problem.)  Does anyone have any thougts on how to proceed?

Donn Terry
Speaking, of course, only for myself.
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>, gdb@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14533.8241.716311.478074@kwikemart.cygnus.com>
References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com>
X-SW-Source: 2000-q1/msg00559.html
Content-length: 3075

Eli Zaretskii writes:
 > 
 > > dir needs no confirmation if not invoked from tty !
 > 
 > Did you actually look at the from_tty variable's value inside
 > dir_command?  I don't have the GDB 5.0 binary here, but GDB certainly
 > *does* ask for confirmation if invoked with stdin and stdout
 > redirected, at least in the DJGPP version.  Elena, is that a bug?
 > 

When I try this on solaris, in directory_command(), from_tty is 1,
but the query() function is the one that finds out that it shouldn't
ask the question to the user.

int
query (char *ctlstr,...)
{
  va_list args;
  register int answer;
  register int ans2;
  int retval;

  va_start (args, ctlstr);

  if (query_hook)
    {
      return query_hook (ctlstr, args);
    }

  /* Automatically answer "yes" if input is not from a terminal.  */
  if (!input_from_terminal_p ())
    return 1;
[...]
}

This input_from_terminal_p() function does:

int
input_from_terminal_p ()
{
  return gdb_has_a_terminal () && (instream == stdin) & caution;
}

In my case the gdb_has_a_terminal() returns 0, so the query is not asked.

All seems to work fine fro solaris. What happens on DJGPP? Is
gdb_has_a terminal() returning 1, maybe?


 > Anyway, the basic point is still valid, even if this particular
 > example is not: when stdin is redirected to a file, GDB should turn
 > editing off.

Or just assume that all the queries have yes as automatic answer,
which is what I always thought it was doing.

 > 
 > > I think its because y is not a valid GDB command !
 > 
 > Invalid commands don't cause GDB to exit, they just result in an error
 > message.  It would be inconceivable to have GDB exit every time I
 > mistype a command ;-).

Yes, the 'y''s  are just generating errors. 

Here is what I get:

kwikemart.cygnus.com: 9 % cat commands
file testsuite/gdb.base/break
dir
y
dir .
break main
run
q
y


kwikemart.cygnus.com: 8 % ./gdb -nw -nx < commands
GNU gdb 4.18.1 (UI_OUT)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.5.1".
(gdb) file testsuite/gdb.base/break
Reading symbols from testsuite/gdb.base/break...done.
(gdb) dir
Source directories searched: $cdir:$cwd
(gdb) y
Undefined command: "y".  Try "help".
(gdb) dir .
Source directories searched: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb:$cdir:$cwd
(gdb) break main
Breakpoint 1 at 0x10824: file /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c, line 75.
(gdb) run
Starting program: /kwikemart/homer/ezannoni/flathead-dev/solaris/gdb/testsuite/gdb.base/break 

Breakpoint 1, main (argc=1, argv=0xeffff124, envp=0xeffff12c)
    at /kwikemart/marge/ezannoni/flathead-dev/devo/gdb/testsuite/gdb.base/break.c:75
75          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited */
(gdb) q



Elena
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "H . J . Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, shebs@apple.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for gnu-regex
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5mvh2yugpy.fsf@jtc.redbacknetworks.com>
References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <20000307211842.C1573@lucon.org>
X-SW-Source: 2000-q1/msg00589.html
Content-length: 1401

>>>>> "hjl" == H J Lu <hjl@lucon.org> writes:
hjl> The current master copy of GNU regex is in glibc. I'd like to be
hjl> able to compile gdb on a known good glibc base system using the
hjl> GNU regex in glibc. 

The problem, as I see it, with linking with a host's regex library is
that gdb does not know whether or not it is "good".  We could write an
autoconf test that attempts to verify the library, or some heuristic
like __GLIBC__ && __GLIBC__ >= 2, but neither is as safe as using the
known good version of the library that is bundled with GDB.  One could
argue that if we're worried about regex, why aren't we worried about a
hundred other things and provide local copies of them.  I'll concede
that that would be silly, but I believe that historical problems with
the regex code makes it a special case.

Having said all that, I'm not opposed to using the host regex.  I'd
like to see us change the regex usage within GDB to use the POSIX.2
API so that we can link with any modern hosts library.  But since the
benefits are small and the risks large, I think it's not the type of
change we want to be making while were trying to wrap up a release.

hjl> I don't want to spend time to check if gdb has the updated regex
hjl> or not.

It doesn't matter much to me.  It's a known good implementation that
works well enough for GDB's purposes.  

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A48875.B520ED34@apple.com>
References: <38A34041.B443DAFB@apple.com> <bitzw8fvy.fsf@rtl.cygnus.com> <38A46C5C.F8301644@apple.com> <200002112037.PAA02309@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00233.html
Content-length: 1623

Jim Kingdon wrote:

> But I guess the GCC system makes sense to me.  If something is enough
> of an issue to be a "technical controversy" in the sense of something
> people would escalate to the chief technical maintainer/team, you kind
> of want to get people on board as much as possible.  Because if you
> proceed without _some_ level of consensus (not among the whole world,
> but at least among a small group of people most involved), then it
> creates various kinds of pain.
> 
> I mean, there is almost always a way out (e.g. make it an option or
> something, if there really a demand for both solutions).

The hard part comes when somebody has to make a single choice.  For
instance, Linus has often had to make arbitrary decisions, in some
cases without necessarily being the big PCMCIA-PS/2-bridge :-) expert.
But in general people agree that his involvement has been better for
Linux' continued evolution than not.  Could a committee have done as
well?  Hard to say.

> One thing I don't want to be single-string is the process of making
> checkins which are believed to be relatively uncontroversial.  Right
> now there is a big problem when the person listed in MAINTAINERS for a
> particular file gets busy or is on vacation or whatever.  Or to put it
> another way, being a maintainer should grant you the right to overrule
> other people but it shouldn't grant you the right to stop things in
> their tracks.  Or something like that.

Absolutely.  I hope that every maintainer has sent in their login info
and ssh keys and all, there should be no obstacle to them making
their own commits now, right?

Stan
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Another Issue for 5.0
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AC4EC7.E3F1EEDE@apple.com>
References: <Pine.LNX.4.10.10002170818250.24672-100000@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00332.html
Content-length: 1054

Daniel Berlin wrote:
> 
> IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should
> really be fixed for 5.0.
> I have patches to do this (in fact, i'm about to send another jumbo patch
> to gdb-patches with it all combined so i don't have to keep emailing it to
> people :P), with no regressions, well, actually, that's not true.
> Some overload resolution things that were xfail before in the testsuite
> now pass.
> Sorry about that. I'll try to make sure i keep the broken things broken in
> the future. :P

:-)

> But, anyway, i get about 5-10 emails a week asking for those patches.
> Even on HP using aCC, where overload resolution works, you get benefits
> because i added support for references in overloads, and fixed a problem
> where the compares against function names were whitespace sensitive where
> they shouldn't have been (so operator [] would be considered the same
> function as operator[] when we were hunting down overloads).

This all sounds great!  Are there any obstacles to just installing the
patches?

Stan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: dan@cgsoftware.com, gdb@sourceware.cygnus.com
Subject: Re: Odd, ptrace_getregs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CDE483.C09982B8@cygnus.com>
References: <Pine.LNX.4.10.10003130853520.6968-100000@localhost.localdomain> <200003131833.TAA19979@landau.wins.uva.nl>
X-SW-Source: 2000-q1/msg00693.html
Content-length: 505

Mark Kettenis wrote:

> I was silently hoping nobody would notice :-(.  I corrected a typo in
> configure.in, but forgot to run autoconf before checking it in.  It's
> basically harmless since it is only the printing of the value that's
> broken.  I just hoped that someone would find the need to regenerate
> configure soon.  Feel free to check in a regenerated autoconf.

Have a look for the fateful phrase ``Fix typo.'' in the ChangeLogs :-) 
It should make you feel like you're not alone :-)

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <389F6110.A54017D@cygnus.com>
References: <389EC815.BC34F3E6@cygnus.com> <20000207112957.A27486@cygnus.com>
X-SW-Source: 2000-q1/msg00140.html
Content-length: 2240

Jason Molenda wrote:
> 
> On Tue, Feb 08, 2000 at 12:26:45AM +1100, Andrew Cagney wrote:
> 
> > With that in mind, I've tentatively planned: two weeks of
> > patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week
> > of last minute checks; and then the 5.0 release (29/2 2000-02-29?).
> > (Everyone is free to roll on the floor laughing at this point :-)
> 
> I think this is too aggressive.  If we had the old source base, maybe it
> would be tenable, but the new repository has mixed the old GDB sources
> with a BFD that hasn't been sync'ed for something like six months.
> And there hasn't been a binutils release in over a year and a half--so
> the stability of binutils across a wide array of platforms has to be
> considered.

I make an ambid claim, everyone else steps up to the table with their
personal agenda, we all start to negotiate .... :-)

> Maybe it would be better to get some test results from a variety of common
> Unix platforms and decide based on how things look.  NB cygwin support
> in binutils is noticably broken -- it will take at least a little work
> to get that resolved.

Yes, more than anything else I should be interested build/test results. 
Thanks for reminding me :-)

> On the other hand, I do agree that a release will go much more smoothly
> now that the repository is on sourceware.

Yes, turn around time once a patch is approved is going to tend to zero.
Ya!

Any way, you will have noticed that I've (for the first time ever?)
given an approximate date for the major release that will follow 5.0. 
I've done it for two reasons:

	o	to make it clear how quickly this release
		really should come out.

	o	to make it clear that if something misses
		the 5.0 boat then 5.1 will be departing
		less than 6 months later.
		
Given that this is a real departure from GDB's previous habits (1-2 year
release cycles) I suspect I'm going to have difficulty convincing people
- I can but try :-).

I think of 5.0 as a consolidation of the significant amount of
re-engineering that has gone on over the last year.  For it I'm only
going to be worried about major failures or serious losses of
functionality.  Enhancements are for 5.1.

> MHO

Always more than welcome :-)

	enjoy,
		Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: GDB <gdb@sourceware.cygnus.com>
Subject: Does gdb support calling C++ member functions?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000114080427.A23281@lucon.org>
X-SW-Source: 2000-q1/msg00032.html
Content-length: 105

Does gdb support calling C++ member functions? I cannot get it
to work. Any suggestions?

Thanks.


H.J.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Paul Breed <pbreed@yahoo.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: GDB/Coldfire bug
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA4E9A.87C39EFA@cygnus.com>
References: <20000125215209.14490.qmail@web3501.mail.yahoo.com>
X-SW-Source: 2000-q1/msg00306.html
Content-length: 1451

Paul Breed wrote:
> 
> I'm a bit lost on how to solve my GDB problem.
> If this is the wrong newslist can you suggest the
> proper one?
> 
> I am trying to use GDB/Insite in a cross compiler
> environment.  I have a S/W GDB Stub running on the
> Coldfire.  It seems to work great.
> 
>  GDB seems to have some problems....
>   c -> continue works.
>   s -> Step works.
>   break x -> works.
>   info locals works etc...
> 
>   n ->Step over does not work.  It tries to read
> things off the stack and gets confused.
> 
> >From what research I've done online I believe this
> problem is not really GDB, I believe it is a problem
> with the debugging information generated by the
> compiler. (gcc 2.95.2 configured for m68k-elf)

Ah.  m68k.  One thing.  I recently fixed a bug to do with m68k stack
dumps - a back trace would fall off the end of the stack.

Was this with the most recent version of GDB?

	Andrew

Wed Dec  8 19:56:48 1999  Andrew Cagney  <cagney@b1.cygnus.com>

        * frame.h, blockframe.c: Rename default_frame_chain_valid to
        file_frame_chain_valid.  Rename alternate_frame_chain_valid to
        func_frame_chain_valid.

        * config/sparc/tm-sparclite.h, config/mips/tm-mipsv4.h,
        config/m88k/tm-delta88v4.h, config/m68k/tm-m68kv4.h,
        config/m68k/tm-monitor.h, config/i386/tm-i386nw.h,
        config/i386/tm-i386v4.h, config/h8300/tm-h8300.h: Update.
        * mips-tdep.c (mips_gdbarch_init): Update.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@delorie.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: i386_register_raw_size[]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002232100.e1NL0nE00718@delius.kettenis.local>
References: <200002231928.OAA18661@indy.delorie.com>
X-SW-Source: 2000-q1/msg00387.html
Content-length: 2799

   Date: Wed, 23 Feb 2000 14:28:19 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>


   i386-tdep.c defines the array used to compute REGISTER_RAW_SIZE
   thusly:

       /* i386_register_raw_size[i] is the number of bytes of storage in the
	  actual machine representation for register i.  */
       int i386_register_raw_size[MAX_NUM_REGS] = {
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	  4,  4,  4,  4,
	 10, 10, 10, 10,
	 10, 10, 10, 10,
	  4,  4,  4,  4,    <<<<<
	  4,  4,  4,  4,    <<<<<
	 16, 16, 16, 16,
	 16, 16, 16, 16,
	  4
       };

   The registers marked with "<<<<<" are the ones I want to discuss.
   These are control, status, and tag words, and the FP instruction
   address and operands.  The ``raw'' part of the name and the comment
   imply that these should have the same size as they are saved by the
   low-level debug support functions on the target machine.  I interpret
   that as the layout in memory of the data saved by FSAVE and similar
   instructions.

I think ``raw'' implies that the data isn't yet interpreted by GDB
yet, i.e. it is in the target byte order.

   However, the above definition of i386_register_raw_size[] does not
   follow the FPU state layout as saved by FSAVE.  For example, the
   actual length of the control/status/tag words is 2 bytes, not 4, and
   the last register, the opcode occupies the 2 upper bytes of the same
   4-byte word as the FP instruction selector.

Messy ain't it?  That, the fact that there exist other i386
instructions that use a different layout to store the same data, and
the possibility of other OS'es that present the data ina very
different layout, were the reasons to simply pretend that these are
32-bit registers.  This was discussed in detail last fail.  I believe
the start of the thread is:

http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00033.html

   I don't have any problems to create an illusion in go32-nat.c that the
   FP register layout is like implied by i386_register_raw_size[],
   especially if it turns out that DJGPP is the only x86 target which
   doesn't already comply with this layout.  But is this really the
   intent--to have all x86 targets use the same raw layout of registers,
   and if so, why do we need the corresponding virtual_size array and
   macros?

Yes, that's what you are supposed to do!  Look at i386gnu-nat.c and
i386-linux-nat.c to see examples.  It is really the intent to have the
same layout on all x86 targets, since this makes it easier to use the
same GDB for different x86 targets.  The virtual_size array and the
macro's are still necessary, since the raw data still needs to be
interpreted to take into account differences in endianness or floating
point types if GDB runs on a host with a different architecture than
the target.

Mark
From brg@sartre.dgate.ORG Sat Apr 01 00:00:00 2000
From: "Brian R. Gaeke" <brg@sartre.dgate.ORG>
To: Stan Shebs <shebs@apple.com>
Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Should GCC tell GDB about its optimizations?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000303173847.A1487@celes.dgate.ORG>
References: <38C051C3.260D666B@apple.com>
X-SW-Source: 2000-q1/msg00532.html
Content-length: 1596

And then spake Stan Shebs, as follows:
> Ideally of course, GCC would issue lots of amazingly detailed debug info,
> and GDB would use it to reconstruct and report program state just as the
> programmer expects to see it.  But today, the result is just lame; hackers
> trying to debug get lots of squirrelly behavior from GDB.  The problem is
> that they don't know whether the randomness is due to bugs in the program,
> or to the effect of the optimizer.  So the suggestion came up to have GCC
> issue debug info stating what optimizations have been applied to a file,
> and to have GDB report that information per-function, so that users could
> lower their expectations appropriately.

You may (or perhaps may not) find some of the material Caroline Tice has
worked on here at UCB useful -- ISTR she was investigating debugging
optimized code and did work on a compiler that outputted a lot of
information on the transformations that were applied to the code (and
debugging tools that used it.)

Disclaimer: I don't have any direct knowledge of how her code did what
it did, so I can't really be of much help -- but I just thought that
her dissertation talk sounded a lot like what you are trying to do...

http://sunsite.berkeley.edu/Dienst/UI/2.0/Describe/ncstrl.ucb/CSD-99-1077
http://www.cs.berkeley.edu/~cmtice/

-Brian

-- 
Brian R. Gaeke, brg@sartre.dgate.ORG -- PGP/GPG gleefully accepted
"the iguana / in the petshop window on St Catherine Street / crested,
 royal-eyed, ruling / its kingdom of water-dish and sawdust / dreams of
 sawdust" - Margaret Atwood, "Dreams of the Animals"
From Rene.Affourtit@pemstar.nl Sat Apr 01 00:00:00 2000
From: Rene.Affourtit@pemstar.nl
To: ecos-discuss@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: cl7111 and gdb problem
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <OF616F8594.4CEC3BB0-ONC12568A9.004FE2E7@pemstar.nl>
X-SW-Source: 2000-q1/msg00756.html
Content-length: 2154

hello,

I have a question concerning the use of the arm-elf-gdb debugger and the
CL7111-2 development board.

When trying to talk to angel in the cl7111 board using the rdi protocol as
described in the documentation gdb prints the following message: "RDI_open:
undefined error message, should reset target" and does not respond anymore.
I was wondering if anyone else has experienced this problem. There was a
similar message in feb. 2000 (subject line : Problem using Insight on ARM7
PID for debugging a ecos application), but I could not find an answer in
the mailing list archive.

any help will be appreciated.
     Rene Affourtit


BTW: Is anybody else using the cl7111 target?

Teh target system uses  Angel version 1.04.

bash.exe-2.02$ arm-elf-gdb --version
GNU gdb 4.17-ecosSWtools-arm-990321
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.  This version of GDB is
supported
for customers of Cygnus Solutions.  Type "show warranty" for details.
This GDB was configured as "--host=i586-cygwin32 --target=arm-elf".
bash.exe-2.02$

bash.exe-2.02$ arm-elf-gdb
GNU gdb 4.17-ecosSWtools-arm-990321
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.  This version of GDB is
supported
for customers of Cygnus Solutions.  Type "show warranty" for details.
This GDB was configured as "--host=i586-cygwin32 --target=arm-elf".
(gdb) set remotebaud 115200
(gdb) target rdi com1
        DEBUG: Buffer allocated in angel_RDI_open(type=10).
        negotiate_params
        sent negotiate packet
RDI_open: undefined error message, should reset target
        DEBUG: Entered angel_RDI_info.
        DEBUG: RDIInfo_Target.
        wait_for_debug_message waiting for 80010001

(indented lines are debug information genrated by gdb (rebuilt gbb with
debug info on in ardi.c)