GDB 5.0 works only at 9600 bps?

GDB 5.0 works only at 9600 bps?

[Joel Brenner]

Hi, I've just installed GNU developement toolchain for arm-elf target
under Linux and It works fine. I've just two  questions:
- Insight 5.0 talk with Angel only at 9600 bps. Are there not
possibilities to do this faster?
-it's possible to use Macraigor's wiggler with gdb or insight?

Thanks a lot for help!

Re: GDB 5.0 works only at 9600 bps?

[Fernando Nasser]

Joel Brenner wrote:
> 
> Hi, I've just installed GNU developement toolchain for arm-elf target
> under Linux and It works fine. I've just two  questions:
> - Insight 5.0 talk with Angel only at 9600 bps. Are there not
> possibilities to do this faster?
> -it's possible to use Macraigor's wiggler with gdb or insight?
> 
> Thanks a lot for help!

It goes up to 115200.

Get a newer Insight snapshot.



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From gjertsen@us.ibm.com Tue Dec 12 09:27:00 2000
From: gjertsen@us.ibm.com
To: Daniel Berlin <dberlin@redhat.com>
Cc: kevinb@cygnus.com (Kevin Buettner), bug-gdb@gnu.org, gdb@sources.redhat.com
Subject: Re: gdb 5.0 "ia64-unknown-linux" segv error
Date: Tue, 12 Dec 2000 09:27:00 -0000
Message-id: <852569B3.005FE686.00@d54mta01.raleigh.ibm.com>
X-SW-Source: 2000-12/msg00070.html
Content-length: 2098

I've upgraded g++ / toochain and that fixed the problem occuring in gdb
(used 1002 toolchain ... 1204 was giving me a headache).
Turbolinux apparently is using the 0719 snapshot of the toolchain which was
right before this self-referential problem with g++ was fixed.

Thanks for the quick help,

--Rob

Daniel Berlin <dberlin@redhat.com>@cygnus.com on 12/09/2000 07:16:26 PM

Sent by:  dberlin@cygnus.com


To:   kevinb@cygnus.com (Kevin Buettner)
cc:   Robert K Gjertsen/Austin/IBM@IBMUS, bug-gdb@gnu.org,
      gdb@sources.redhat.com
Subject:  Re: gdb 5.0 "ia64-unknown-linux" segv error



kevinb@cygnus.com (Kevin Buettner) writes:

> On Dec 8,  3:34pm, gjertsen@us.ibm.com wrote:
>
> > I've transferred the ~24Mb file, testcase.tar.gz, over to the incoming
> > location.
> >
> > The name/size information is:
> >
> > -rw-rw-r--   1 gjertsen gjertsen 24473202 Dec  8 15:33 testcase.tar.gz
> >
> > tar file contents:
> > -rwxrwxr-x   1 gjertsen gjertsen 74072196 Dec  8 15:30 mmfsd
> > -rw-rw-r--   1 gjertsen gjertsen  3158277 Dec  8 15:30 mmfsd.map
>
> Thanks for the test case.  I am able to reproduce the bug that you
> reported.  I've done some investigation and I now wonder what tools
> you used to create mmfsd.  (I.e, I wonder if the bug is actually in
> the compiler.)  I've used "readelf -wi" to look at the debugging
> symbols in mmfsd and I see the following:
>
>  <1><96d50>: Abbrev Number: 12 (DW_TAG_typedef)
>      DW_AT_name        : ulong
>      DW_AT_decl_file   : 12
>      DW_AT_decl_line   : 59
>      DW_AT_type        : <96d50>
>
> I'm not a DWARF2 expert, but it looks to me like the above is a
> self referential typedef.  This would explain why you're seeing
> the infinite recursion in dwarf2read.c.
>
Yes, it is, and it's illegal.
This happened a while ago in G++, I reported it, and nobody could
reproduce with the current CVS, so it appears to be fixed.
Someone had sent me an executable with this kind of broken DWARF2
generated by GNU C++ 2.96 20000719.
It was unreproducable on 7/24, according to Jason Merril.
Search gcc-bugs for self-referential.
--Dan

Re: GDB 5.0 works only at 9600 bps?

[Jens-Christian Lache]

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

Hi!
Am Die, 12 Dez 2000 schrieben Sie:
> Joel Brenner wrote:
> > 
> > Hi, I've just installed GNU developement toolchain for arm-elf target
> > under Linux and It works fine. I've just two  questions:
> > - Insight 5.0 talk with Angel only at 9600 bps. Are there not
> > possibilities to do this faster?
> > -it's possible to use Macraigor's wiggler with gdb or insight?
> > 
> > Thanks a lot for help!
> 
> It goes up to 115200.
> 
> Get a newer Insight snapshot.
I did so. But:
lache@lab04:~ > tools/bin/arm-elf-gdb -nw c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
GNU gdb 20001212
Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) target rdi /dev/ttyS1
Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.11a) for AT91EB0x (1.01)
Angel Debug Monitor rebuilt on Sep 14 1998 at 14:52:22
Serial Rate:   9600
Connected to ARM RDI target.
(gdb) quit
The program is running.  Exit anyway? (y or n) y
lache@lab04:~ > tools/bin/arm-elf-gdb -nw -b 115200 c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
GNU gdb 20001212
Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) target rdi /dev/ttyS1

nothing ...., like before. It hangs. The binary looks like:
lache@lab04:~ > ll tools/bin/arm-elf-gdb
-rwxr-xr-x   1 lache    hiwi      9313630 Dez 13 10:13 tools/bin/arm-elf-gdb

I really would love to have a rate of 115200! Could there be any interference
with my old version?

> 
> 
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From eliz@delorie.com Wed Dec 13 03:41:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: fnasser@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 03:41:00 -0000
Message-id: <200012131141.GAA14558@indy.delorie.com>
References: <3A368138.A7360C4A@cygnus.com>
X-SW-Source: 2000-12/msg00080.html
Content-length: 527

> Date: Tue, 12 Dec 2000 14:49:12 -0500
> From: Fernando Nasser <fnasser@cygnus.com>
>
> enum var_types
>   {

Why is a `double' missing from this enum?

> /* Obtain the current value of a global. */
> 
> extern gdb_global_rc
>            gdb_global_get_value (gdb_global_handle global, char **cur_val);

Shouldn't the last argument be a "void **"?

> /* Set a new value in a global and notify consumers. */
> 
> extern gdb_global_rc
>            gdb_global_set_value (, char *new_val);

Something (a handle?) is missing here.
From fnasser@cygnus.com Wed Dec 13 06:29:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jens-Christian Lache <lache@tu-harburg.de>
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.0 works only at 9600 bps?
Date: Wed, 13 Dec 2000 06:29:00 -0000
Message-id: <3A378766.F220EA79@cygnus.com>
References: <3A35E72C.3BDF0D8B@tchip.com> <3A36365E.D2FB30C3@cygnus.com> <00121310422900.00869@lab04>
X-SW-Source: 2000-12/msg00081.html
Content-length: 3520

Hi,

You must use the command:

set remotebaud 115200

BEFORE

issuing your target command.

You can also use the option "-b" when starting gdb like:

tools/bin/arm-elf-gdb -nw -b 115200


I use this frequently and it works fine.

However, note that some boards do not support faster speeds.
I have a $150 ARM AEB development board and the Angel monitor
in there does not get the line speed up.

If you still have problems, there is a RDI log facility contributed by
Grant Edwards that can be used to see the protocol messages.

At the very beginning, the communication speed is 9600.
GDB sends a list of acceptable speeds to the target and it responds
with the best it can do.  They both switch the line to that speed
at that moment.

But I believe the set remotebaud will be enough.

Fernando


Jens-Christian Lache wrote:
> 
> Hi!
> Am Die, 12 Dez 2000 schrieben Sie:
> > Joel Brenner wrote:
> > >
> > > Hi, I've just installed GNU developement toolchain for arm-elf target
> > > under Linux and It works fine. I've just two  questions:
> > > - Insight 5.0 talk with Angel only at 9600 bps. Are there not
> > > possibilities to do this faster?
> > > -it's possible to use Macraigor's wiggler with gdb or insight?
> > >
> > > Thanks a lot for help!
> >
> > It goes up to 115200.
> >
> > Get a newer Insight snapshot.
> I did so. But:
> lache@lab04:~ > tools/bin/arm-elf-gdb -nw c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
> GNU gdb 20001212
> Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
> (gdb) target rdi /dev/ttyS1
> Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.11a) for AT91EB0x (1.01)
> Angel Debug Monitor rebuilt on Sep 14 1998 at 14:52:22
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> lache@lab04:~ > tools/bin/arm-elf-gdb -nw -b 115200 c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
> GNU gdb 20001212
> Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
> (gdb) target rdi /dev/ttyS1
> 
> nothing ...., like before. It hangs. The binary looks like:
> lache@lab04:~ > ll tools/bin/arm-elf-gdb
> -rwxr-xr-x   1 lache    hiwi      9313630 Dez 13 10:13 tools/bin/arm-elf-gdb
> 
> I really would love to have a rate of 115200! Could there be any interference
> with my old version?
> 
> >
> >
> >
> > --
> > Fernando Nasser
> > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> > 2323 Yonge Street, Suite #300
> > Toronto, Ontario   M4P 2C9
> --
> 
> Jens-Christian Lache
> Technische Universitaet Hamburg-Harburg
> www.tu-harburg.de/~sejl1601
> Mail:
> lache@tu-harburg.de
> lache@ngi.de
> Tel.:
> +0491759610756

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fnasser@cygnus.com Wed Dec 13 06:38:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 06:38:00 -0000
Message-id: <3A3789A6.7D0C3A60@cygnus.com>
References: <3A368138.A7360C4A@cygnus.com> <200012131141.GAA14558@indy.delorie.com>
X-SW-Source: 2000-12/msg00082.html
Content-length: 1345

Thank you for your comments Eli.


Eli Zaretskii wrote:
> 
> > Date: Tue, 12 Dec 2000 14:49:12 -0500
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > enum var_types
> >   {
> 
> Why is a `double' missing from this enum?
> 

Because I just used whatever we currently have in commands.h,
which implies we do not have any doubles yet settable with
set/show commands.

I had added a "(initially)" in my draft but I somehow took it off.



> > /* Obtain the current value of a global. */
> >
> > extern gdb_global_rc
> >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> 
> Shouldn't the last argument be a "void **"?
> 

I initially defined it as a void ** but then I realized out set/show
facility and the commands.h stuff use char **.

To minimize the conversion effort I thought of keeping it like it is now.

I wonder if this was not done this way due to some compatibility problem.
Maybe the reason no longer exists anyway.


> > /* Set a new value in a global and notify consumers. */
> >
> > extern gdb_global_rc
> >            gdb_global_set_value (, char *new_val);
> 
> Something (a handle?) is missing here.

Ops!  Thanks.  You are right, it is the handle.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fnasser@cygnus.com Wed Dec 13 06:51:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sources.redhat.com
Subject: RFC: gdbglobals.[ch]  REPOST
Date: Wed, 13 Dec 2000 06:51:00 -0000
Message-id: <3A378C92.E2033698@cygnus.com>
X-SW-Source: 2000-12/msg00083.html
Content-length: 5435

(I believe I had posted my first draft by mistake, and also posted
 the most recent version afterwards.  Sorry.

 Here it is the latest with the fix for the missing parameter pointed
 by Eli)
  


I guess you are all aware of the problem we currently have with variables
being needed somewhere else and then becoming globals (or spinning off
global accessor functions).

This is hitting the user interfaces as they have facilities to set/show
some of these variables (see, for instance, the inferior_args case).

As per Andrew's request, I have wrote down a proposal based on a private
conversation we had so that we can see what people think about it.

Here it is:

GDB GLOBALS
===========

GDB "globals" allow gdblib information to be shared with other GDB components,
like the user interfaces or script languages.
It provides a standard way to access and share data.

Data will be registered by the provider and will have a symbolic "name"
so that other components interested in accessing it can use this name to
request access symbolically.

It will also have a "type", which will be (initially) one of:

enum var_types
  {
    /* "on" or "off".  *VAR is an integer which is nonzero for on,
       zero for off.  */
    var_boolean,

    /* "on" / "true" / "enable" or "off" / "false" / "disable" or
       "auto.  *VAR is an ``enum cmd_auto_boolean''.  NOTE: In general
       a custom show command will need to be implemented - one that
       for "auto" prints both the "auto" and the current auto-selected
       value. */
    var_auto_boolean,

    /* Unsigned Integer.  *VAR is an unsigned int.  The user can type 0
       to mean "unlimited", which is stored in *VAR as UINT_MAX.  */
    var_uinteger,

    /* Like var_uinteger but signed.  *VAR is an int.  The user can type 0
       to mean "unlimited", which is stored in *VAR as INT_MAX.  */
    var_integer,

    /* String which the user enters with escapes (e.g. the user types \n and
       it is a real newline in the stored string).
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_string,

    /* String which stores what the user types verbatim.
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_string_noescape,

    /* String which stores a filename.
       *VAR is a malloc'd string, or NULL if the string is empty.  */
    var_filename,

    /* ZeroableInteger.  *VAR is an int.  Like Unsigned Integer except
       that zero really means zero.  */
    var_zinteger,

    /* Enumerated type.  Can only have one of the specified values.  *VAR is a
       char pointer to the name of the element that we find.  */
    var_enum
  };

The libgdb module registering the global will provide the name, type and address
of the data.  It can also provide (optionally) a call back routine to be invoked
if the data is changed.  A handle is returned.

The GDB component trying to access the data will request it by name and provide
a call back routine (optional) to be invoked when the data changes.
It will receive, on success, a handle to be used when invoking the accessor routines.

Accessor routines will be provided to set or get the data.  Data shall only be accessed
through these functions, so proper notification is given to registered consumers.


Tentative API:

/* Register a global and optionally a callback. */

extern gdb_global_handle 
           gdb_global_register (char *name, enum var_types type, char *addr,
                                const char *enumlist[],
                                gdb_global_callback_ftype notify_me);

/* Get handle to access a global and optionally register callback. */

extern gdb_global_handle
           gdb_global_request (char *name, enum var_types type,
                               gdb_global_callback_ftype notify_me);

/* Obtain the current value of a global. */

extern gdb_global_rc
           gdb_global_get_value (gdb_global_handle global, char **cur_val);

/* Obtain all possible values for a var_enum global.
   Returns pointer to the NULL-terminated list of pointers to the values. */

extern gdb_global_rc
           gdb_global_get_enum_values (gdb_global_handle global, char **values[]);

/* Set a new value in a global and notify consumers. */

extern gdb_global_rc
           gdb_global_set_value (gdb_global_handle global, char *new_val);

/* Replace the global value with a new implementation.  Notify consumers. */

extern gdb_global_rc
           gdb_global_replace (gdb_global_handle global, char *new_addr,
                               const char *enumlist[]);

/* Obtain the name, type and current value of a global given the handle. */

extern gdb_global_rc
           gdb_global_info (gdb_global_handle global,
                            char *name, enum var_types type, char **cur_val);

/* Obtain a list of all globals that match a regular expression,
   with name, type and current value. 
   Returns malloc'ed NULL-terminated list of handles. */

extern gdb_global_rc
           gdb_global_list (struct re_pattern_buffer *regex, gdb_global_handle **list);

/* Callback function type. */

typedef void (gdb_global_callback_ftype) (gdb_global_handle global,
                                          gdb_global_handle new_handle);
                                         


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From fche@redhat.com Wed Dec 13 07:26:00 2000
From: fche@redhat.com (Frank Ch. Eigler)
To: Joel Sherrill <joel.sherrill@OARcorp.com>
Cc: gdb@sources.redhat.com, newlib@sources.redhat.com, crossgcc@sources.redhat.com
Subject: Re: tx39 simulator timer questions
Date: Wed, 13 Dec 2000 07:26:00 -0000
Message-id: <o5wvd48hs5.fsf@toenail.toronto.redhat.com>
References: <3A3545D6.6137C189@OARcorp.com>
X-SW-Source: 2000-12/msg00084.html
Content-length: 698

Joel Sherrill <joel.sherrill@OARcorp.com> writes:

: [...]
: I hate to crosspost like this but I need to find someone who is
: knowledgeable about the TX3904 and/or its simulator in gdb.  

The ChangeLog says all!

: [...]
: But between an error reading the PDF Toshiba documentation :)
: and the simulator, I am confused about the requirements/sequence 
: to make the timer do this.  [...]

It may help if I clarify that this extension to the plain mips
simulator was done in order to let eCos run on it.  So, if you take a
look at how the eCos tx39 HAL talks to the hardware, and you copy the
relevant couple of lines, chances are that the sim will work
sufficiently well for RTEMS too.


- FChE
From lache@tu-harburg.de Wed Dec 13 07:38:00 2000
From: Jens-Christian Lache <lache@tu-harburg.de>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.0 works only at 9600 bps?
Date: Wed, 13 Dec 2000 07:38:00 -0000
Message-id: <00121316374500.00993@lab05>
References: <3A35E72C.3BDF0D8B@tchip.com> <00121310422900.00869@lab04> <3A378766.F220EA79@cygnus.com>
X-SW-Source: 2000-12/msg00085.html
Content-length: 4267

Hi Fernando!
I did use the the -b option (see below). I just wanted to show
with the first lunch of gdb that it works on 9600bps. In the second 
it gets started with -b 115200. It always hangs with a different
speed than the default speed.

I have seen 57600bps under win/multi (gr**nhills inc.) with
my ATEB01, so it is not the board.

jc

Am Mit, 13 Dez 2000 schrieben Sie:
> Hi,
> 
> You must use the command:
> 
> set remotebaud 115200
> 
> BEFORE
> 
> issuing your target command.
> 
> You can also use the option "-b" when starting gdb like:
> 
> tools/bin/arm-elf-gdb -nw -b 115200
> 
> 
> I use this frequently and it works fine.
> 
> However, note that some boards do not support faster speeds.
> I have a $150 ARM AEB development board and the Angel monitor
> in there does not get the line speed up.
> 
> If you still have problems, there is a RDI log facility contributed by
> Grant Edwards that can be used to see the protocol messages.
> 
> At the very beginning, the communication speed is 9600.
> GDB sends a list of acceptable speeds to the target and it responds
> with the best it can do.  They both switch the line to that speed
> at that moment.
> 
> But I believe the set remotebaud will be enough.
> 
> Fernando
> 
> 
> Jens-Christian Lache wrote:
> > 
> > Hi!
> > Am Die, 12 Dez 2000 schrieben Sie:
> > > Joel Brenner wrote:
> > > >
> > > > Hi, I've just installed GNU developement toolchain for arm-elf target
> > > > under Linux and It works fine. I've just two  questions:
> > > > - Insight 5.0 talk with Angel only at 9600 bps. Are there not
> > > > possibilities to do this faster?
> > > > -it's possible to use Macraigor's wiggler with gdb or insight?
> > > >
> > > > Thanks a lot for help!
> > >
> > > It goes up to 115200.
> > >
> > > Get a newer Insight snapshot.
> > I did so. But:
> > lache@lab04:~ > tools/bin/arm-elf-gdb -nw c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
> > GNU gdb 20001212
> > Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
> > (gdb) target rdi /dev/ttyS1
> > Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.11a) for AT91EB0x (1.01)
> > Angel Debug Monitor rebuilt on Sep 14 1998 at 14:52:22
> > Serial Rate:   9600
> > Connected to ARM RDI target.
> > (gdb) quit
> > The program is running.  Exit anyway? (y or n) y
> > lache@lab04:~ > tools/bin/arm-elf-gdb -nw -b 115200 c/internal.sram/bin/internal.sram.tc1_interrupt_handler.arm
> > GNU gdb 20001212
> > Copyright 2000 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 "--host=i686-pc-linux-gnu --target=arm-elf"...
> > (gdb) target rdi /dev/ttyS1
> > 
> > nothing ...., like before. It hangs. The binary looks like:
> > lache@lab04:~ > ll tools/bin/arm-elf-gdb
> > -rwxr-xr-x   1 lache    hiwi      9313630 Dez 13 10:13 tools/bin/arm-elf-gdb
> > 
> > I really would love to have a rate of 115200! Could there be any interference
> > with my old version?
> > 
> > >
> > >
> > >
> > > --
> > > Fernando Nasser
> > > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> > > 2323 Yonge Street, Suite #300
> > > Toronto, Ontario   M4P 2C9
> > --
> > 
> > Jens-Christian Lache
> > Technische Universitaet Hamburg-Harburg
> > www.tu-harburg.de/~sejl1601
> > Mail:
> > lache@tu-harburg.de
> > lache@ngi.de
> > Tel.:
> > +0491759610756
> 
> -- 
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
-- 


Jens-Christian Lache
Technische Universitaet Hamburg-Harburg
www.tu-harburg.de/~sejl1601
Mail:
lache@tu-harburg.de
lache@ngi.de
Tel.:
+0491759610756
From fnasser@cygnus.com Wed Dec 13 08:17:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Jens-Christian Lache <lache@tu-harburg.de>
Cc: gdb@sources.redhat.com
Subject: Re: GDB 5.0 works only at 9600 bps?
Date: Wed, 13 Dec 2000 08:17:00 -0000
Message-id: <3A37A0B7.83105046@cygnus.com>
References: <3A35E72C.3BDF0D8B@tchip.com> <00121310422900.00869@lab04> <3A378766.F220EA79@cygnus.com> <00121316374500.00993@lab05>
X-SW-Source: 2000-12/msg00086.html
Content-length: 1933

Jens-Christian Lache wrote:
> 
> Hi Fernando!
> I did use the the -b option (see below). I just wanted to show
> with the first lunch of gdb that it works on 9600bps. In the second
> it gets started with -b 115200. It always hangs with a different
> speed than the default speed.
> 
> I have seen 57600bps under win/multi (gr**nhills inc.) with
> my ATEB01, so it is not the board.
> 

This is the same board as I have.  It seems to be a board monitor bug
When GDB sends the option list (as specified in the ARM document that defines
the protocol), this board replies with some speed (I don't think it is 115200
though) but it does not seem to switch to that speed as promised because GDB
does switch to the indicated speed and cannot communicate with the board
anymore.

As the RDI protocol requires that the handshake starts at 9600, you have to
reset the board so it falls back to that speed before being able to connect
again.

All this can be seen by turning the log on:

(gdb) maintenance rdilogfile /dev/tty
(gdb) maintenance rdilogenable yes 


The software you mentioned probably added a hack to work with this board
but I had no time to experiment with it to figure out what is the speed that
it actually switches to. And I am not sure how I could add something that 
would work with this board without violating the protocol and making GDB
stop working with the other well behaved boards (we have many Angel monitor
targets that speak RDI correctly and switch speeds perfectly).


I will be interested in finding a way to get this to work somehow (I have
the little AEB board).  You can help by getting the handshake messages log.
We may even ask ARM about this (maybe some undocumented protocol extension?
A new version of the monitor is available?).


Regards,
Fernando





-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From joel.sherrill@OARcorp.com Wed Dec 13 09:04:00 2000
From: Joel Sherrill <joel.sherrill@OARcorp.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: gdb@sources.redhat.com, newlib@sources.redhat.com, crossgcc@sources.redhat.com
Subject: Re: tx39 simulator timer questions
Date: Wed, 13 Dec 2000 09:04:00 -0000
Message-id: <3A37A8F7.622D7079@OARcorp.com>
References: <3A3545D6.6137C189@OARcorp.com> <o5wvd48hs5.fsf@toenail.toronto.redhat.com>
X-SW-Source: 2000-12/msg00087.html
Content-length: 1573

"Frank Ch. Eigler" wrote:
> 
> Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> 
> : [...]
> : I hate to crosspost like this but I need to find someone who is
> : knowledgeable about the TX3904 and/or its simulator in gdb.
> 
> The ChangeLog says all!
> 
> : [...]
> : But between an error reading the PDF Toshiba documentation :)
> : and the simulator, I am confused about the requirements/sequence
> : to make the timer do this.  [...]
> 
> It may help if I clarify that this extension to the plain mips
> simulator was done in order to let eCos run on it.  So, if you take a
> look at how the eCos tx39 HAL talks to the hardware, and you copy the
> relevant couple of lines, chances are that the sim will work
> sufficiently well for RTEMS too.

I would like to thank Frank for his help.  I am now getting the 
clock tick and have console output working on the simulator.  

Here are a couple of things that are important to know about
this simulator:

  1.  configure for tx39*-* otherwise the tx39 device support
      and instruction set are not turned on.  [The mips simulator
      configuration is complicated because there are lots of 
      CPU models and ISA variations.]
  2.  The timer counts instructions.  

Frank.. does the simulator have a mode for an R4000 class CPU 
that supports the timer they have? 

> - FChE

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985
From fche@redhat.com Wed Dec 13 09:17:00 2000
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Joel Sherrill <joel.sherrill@OARcorp.com>
Cc: gdb@sources.redhat.com, newlib@sources.redhat.com, crossgcc@sources.redhat.com
Subject: Re: tx39 simulator timer questions
Date: Wed, 13 Dec 2000 09:17:00 -0000
Message-id: <20001213121645.H11639@redhat.com>
References: <3A3545D6.6137C189@OARcorp.com> <o5wvd48hs5.fsf@toenail.toronto.redhat.com> <3A37A8F7.622D7079@OARcorp.com>
X-SW-Source: 2000-12/msg00088.html
Content-length: 789

Hi -

On Wed, Dec 13, 2000 at 10:51:03AM -0600, Joel Sherrill wrote:
: [...]
: Here are a couple of things that are important to know about
: this [tx39] simulator:
: 
:   1.  configure for tx39*-* otherwise the tx39 device support
:       and instruction set are not turned on.  [...]

That, plus use the "--board=jmr3904" option to place the tx39
evaluation board's peripheral models into the address space.

: [...]
: Frank.. does the simulator have a mode for an R4000 class CPU 
: that supports the timer they have? 

None that I know of.


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6N679VZbdDOm/ZT0RAp+cAJ9rgoFHRfLKjsoxNSUMNXIxRsRfaQCbBs+A
9kcBCGqTT6ASXB/SBOFe5TI=
=Mug9
-----END PGP SIGNATURE-----
From eliz@is.elta.co.il Wed Dec 13 10:50:00 2000
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: fnasser@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 10:50:00 -0000
Message-id: <9003-Wed13Dec2000204758+0200-eliz@is.elta.co.il>
References: <3A368138.A7360C4A@cygnus.com> <200012131141.GAA14558@indy.delorie.com> <3A3789A6.7D0C3A60@cygnus.com>
X-SW-Source: 2000-12/msg00089.html
Content-length: 870

> Date: Wed, 13 Dec 2000 14:37:26 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> > > /* Obtain the current value of a global. */
> > >
> > > extern gdb_global_rc
> > >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> > 
> > Shouldn't the last argument be a "void **"?
> 
> I initially defined it as a void ** but then I realized out set/show
> facility and the commands.h stuff use char **.
> 
> To minimize the conversion effort I thought of keeping it like it is now.
> 
> I wonder if this was not done this way due to some compatibility problem.
> Maybe the reason no longer exists anyway.

I suspect that was to pacify non-ANSI/non-ISO compilers.  Since we
don't support those anymore, I'd suggest to use void **.  I'm afraid
that a good ANSI compiler, and with the warning options we now use by
default, will bitch at char **.
From fnasser@cygnus.com Wed Dec 13 11:15:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 11:15:00 -0000
Message-id: <3A37CAAA.36AD9F63@cygnus.com>
References: <3A368138.A7360C4A@cygnus.com> <200012131141.GAA14558@indy.delorie.com> <3A3789A6.7D0C3A60@cygnus.com> <9003-Wed13Dec2000204758+0200-eliz@is.elta.co.il>
X-SW-Source: 2000-12/msg00090.html
Content-length: 1134

Eli Zaretskii wrote:
> 
> > Date: Wed, 13 Dec 2000 14:37:26 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> >
> > > > /* Obtain the current value of a global. */
> > > >
> > > > extern gdb_global_rc
> > > >            gdb_global_get_value (gdb_global_handle global, char **cur_val);
> > >
> > > Shouldn't the last argument be a "void **"?
> >
> > I initially defined it as a void ** but then I realized out set/show
> > facility and the commands.h stuff use char **.
> >
> > To minimize the conversion effort I thought of keeping it like it is now.
> >
> > I wonder if this was not done this way due to some compatibility problem.
> > Maybe the reason no longer exists anyway.
> 
> I suspect that was to pacify non-ANSI/non-ISO compilers.  Since we
> don't support those anymore, I'd suggest to use void **.  I'm afraid
> that a good ANSI compiler, and with the warning options we now use by
> default, will bitch at char **.

OK, I will change that in the final version.

Thanks.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From jtc@redback.com Wed Dec 13 11:16:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 11:16:00 -0000
Message-id: <5mhf48ku7v.fsf@jtc.redback.com>
References: <3A368138.A7360C4A@cygnus.com>
X-SW-Source: 2000-12/msg00091.html
Content-length: 1384

>>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
Fernando> I guess you are all aware of the problem we currently have
Fernando> with variables being needed somewhere else and then becoming
Fernando> globals (or spinning off global accessor functions).
Fernando>
Fernando> This is hitting the user interfaces as they have facilities
Fernando> to set/show some of these variables (see, for instance, the
Fernando> inferior_args case).
Fernando>
Fernando> As per Andrew's request, I have wrote down a proposal based
Fernando> on a private conversation we had so that we can see what
Fernando> people think about it.

Some things that are currently set/show variables would be convient to
access from GDB scripts.  It appears that this proposal would compound
that mistake by having yet another set of variables that cannot be
accessed by GDB's scripting language.

Why not make these regular GDB $ variables?  Then alternate scripting
languages and user interfaces would only need one mechanism to access
GDB variables instead of the two (or three, if this proposal is
adopted) used today.  

One problem would be ensuring a clean namespace so that user's scripts
wouldn't break when new variables are exported from GDB.  I think this
is solvable, and would result in a more coherent GDB/scripting language/
UI layering.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From fnasser@cygnus.com Wed Dec 13 12:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: jtc@redback.com
Cc: gdb@sources.redhat.com
Subject: Re: RFC: gdbglobals.[ch]
Date: Wed, 13 Dec 2000 12:00:00 -0000
Message-id: <3A37D538.85BA2E37@cygnus.com>
References: <3A368138.A7360C4A@cygnus.com> <5mhf48ku7v.fsf@jtc.redback.com>
X-SW-Source: 2000-12/msg00092.html
Content-length: 2583

"J.T. Conklin" wrote:
> 
> Some things that are currently set/show variables would be convient to
> access from GDB scripts.  It appears that this proposal would compound
> that mistake by having yet another set of variables that cannot be
> accessed by GDB's scripting language.
> 

I agree that all the script languages should be able to use the $ variables for
use in expressions and such.  The MI provides this access already, and 
corresponding gdblib calls should also be available.  But  we are talking
about something else here.  Se, for instance, the "inferior_args" thread.   

We are not keeping the set/show variables, which are just variables
(exactly of the same types as the proposed gdbglobals) that have their
addresses exported to the CLI by a function call to the CLI (like add_set_cmd).
We also share other variables by making them globals and turning gdb into a maze.

We are just generalizing the mechanism to *reduce* the ways of doing things. 
The idea is that all set/show variables turn into gdbglobals, as well as all
other global variables.


> Why not make these regular GDB $ variables?  Then alternate scripting
> languages and user interfaces would only need one mechanism to access
> GDB variables instead of the two (or three, if this proposal is
> adopted) used today.
> 
> One problem would be ensuring a clean namespace so that user's scripts
> wouldn't break when new variables are exported from GDB.  I think this
> is solvable, and would result in a more coherent GDB/scripting language/
> UI layering.
> 

Using the gdb convenience ($) variables would be considerably slower as we would
have to search the symbolic space at each use.  Not to mention the type conversion.
Some of the variables we are talking about are used frequently and repeatedly.

Also, some of the values shared may not mean to be accessible by users
(the set/show ones are, but we have other globals).  Making them a $ variable
we would be exposing them to any user.

The gdbglobals also have some special types that can make handling things like
a set of possible values easier.  And we can add more types if necessary.
Compare this with the untyped $ variables...



I think the main reason not to use GDB convenience variables to substitute globals
is that we are talking about two different levels of abstraction.  The gdbglobals is
at the implementation level, while the convenience variables are at the use level.





-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From ashimoda@redhat.com Thu Dec 14 00:08:00 2000
From: "Ataru Shimodaira" <ashimoda@redhat.com>
To: <gdb@sourceware.cygnus.com>
Subject: please help...
Date: Thu, 14 Dec 2000 00:08:00 -0000
Message-id: <LPBBLAMALKMDDBKOPNMKEEGGDOAA.ashimoda@redhat.com>
X-SW-Source: 2000-12/msg00093.html
Content-length: 1356

Dear list.

We got a following inquiry from China.
I do not think we have any support contract with this customer.
How could we cover these questions?
Does our support contract cover them?

Ataru Shimodaira,
Red Hat, Inc.    ashimoda@redhat.com
phone: +81-90-7800-0190, +81-3-3257-0489
fax:     +81-3-3257-0410
----------------------------
From: "luo" <luo@informedia.net.cn>
To: <kpowers@redhat.com>
Subject: help
Date: Sat, 9 Dec 2000 11:54:36 +0800
X-Mailer: Microsoft Outlook Express 5.00.2615.200

Hi,
    I'm come from China,I have bought Net+Lx develop system,but don't buy
ICE,
    I have two questions,Will you give me help?
      (1),how to debug program without ICE.
      (2).how to save information (such as IP address,router),so I need not
to setup this information at  every target start .
      (3).Can I use gdbserver in my ArmNet40 target?
      (4).When I configure and make gdb and gdbserver,There are some
errors,e.g:
          a.FO_REGNUM undefined,
          b.arm_opcode.h not find.
         How I do with those?
       Hope know those as quickly as possiable.
       Thank you very much.
                                                  LuoYi
                                                  Dalian Yongjia Electronic
Co.,Ltd
                                                  2000/12/9
------------------------------------------
From \x03joel.brenner@tchip.com Thu Dec 14 06:03:00 2000
From: Joel Brenner <\x03joel.brenner@tchip.com>
To: gdb@sources.redhat.com, fnasser@gygnus.com
Subject: [Fwd: GDB 5.0 works only at 9600 bps?]
Date: Thu, 14 Dec 2000 06:03:00 -0000
Message-id: <3A38D27B.96089DAB@tchip.com>
X-SW-Source: 2000-12/msg00094.html
Content-length: 2893

Thi is the logfile writed by gdb during the handshake with ANGEL an
AT91EB40:

ADP log file opened at Thu Dec 14 14:39:01 2000

tx: [T=0 L=52] 03 01 00 01 05 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
ff 01 00 00 00 00 c0 00 00 05 00 00 00 00 c2 01 00 00 e1 00 00 00 96 00
00 00 4b 00 00 80 25 00 00
R=00030005 H->T CI_HBOOT:  ADP_ParamNegotiate 00000001 0000c000 00000005
0001c200 0000e100 00009600 00004b00 00002580
ADP log file opened at Thu Dec 14 14:49:53 2000

tx: [T=0 L=52] 03 01 00 01 05 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
ff 01 00 00 00 00 c0 00 00 05 00 00 00 00 c2 01 00 00 e1 00 00 00 96 00
00 00 4b 00 00 80 25 00 00
R=00030005 H->T CI_HBOOT:  ADP_ParamNegotiate 00000001 0000c000 00000005
0001c200 0000e100 00009600 00004b00 00002580
rx: [T=0 L=36] 03 02 01 01 05 00 03 80 00 00 00 00 ff ff ff ff ff ff ff
ff 00 00 00 00 01 00 00 00 00 c0 00 00 00 c2 01 00
R=80030005 H<-T CI_HBOOT:  ADP_ParamNegotiate 00000000 00000001 0000c000
0001c200
tx: [T=0 L=20] 03 02 00 01 06 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
ff
R=00030006 H->T CI_HBOOT:  ADP_LinkCheck
rx: [T=0 L=20] 03 03 02 01 06 00 03 80 00 00 00 00 ff ff ff ff ff ff ff
ff
R=80030006 H<-T CI_HBOOT:  ADP_LinkCheck
tx: [T=0 L=24] 03 01 00 01 03 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
ff 00 00 00 00
R=00030003 H->T CI_HBOOT:  ADP_Reset 00000000
rx: [T=0 L=24] 03 01 01 01 03 00 03 80 ff ff ff ff ff ff ff ff ff ff ff
ff 00 00 00 00
R=80030003 H<-T CI_HBOOT:  ADP_Reset 00000000
rx: [T=0 L=215] 04 02 01 01 00 00 04 80 ff ff ff ff ff ff ff ff ff ff ff
ff f8 00 00 00 f8 07 00 00 01 00 00 00 03 00 00 00 00 00 00 80 01 00 00
00 00 00 00 00 a3 00 00 00 41 6e 67 65 6c 20 44 65 62 75 67 20 4d 6f 6e
69 74 6f 72 20 28 73 65 72 69 61 6c 29 20 31 2e 30 34 20 28 41 64 76 61
6e 63 65 64 20 52 49 53 43 20 4d 61 63 68 69 6e 65 73 20 53 44 54 20 32
2e 35 29 20 66 6f 72 20 41 54 39 31 45 42 34 30 20 28 32 2e 30 30 29 0a
41 6e 67 65 6c 20 44 65 62 75 67 20 4d 6f 6e 69 74 6f 72 20 72 65 62 75
69 6c 74 20 6f 6e 20 41 70 72 20 30 37 20 32 30 30 30 20 61 74 20 31 32
3a 34 30 3a 33 31 0a 53 65 72 69 61 6c 20 52 61 74 65 3a 20 31 31 35 32
30 30 0a 00
R=80040000 H<-T CI_TBOOT:  ADP_Booted 000000f8 000007f8 00000001
00000003 80000000 00000001 00000000 000000a3 65676e41 6544206c 20677562
696e6f4d 20726f74 72657328 296c6169 302e3120 41282034 6e617664 20646563
43534952 63614d20 656e6968 44532073 2e322054 66202935 4120726f 45313954
20303442 302e3228 410a2930 6c65676e 62654420 4d206775 74696e6f 7220726f
69756265 6f20746c 7041206e 37302072 30303220 74612030 3a323120 333a3034
65530a31 6c616972 74615220 31203a65 30323531 00000a30
tx: [T=0 L=24] 04 02 00 01 00 00 04 00 00 00 00 00 ff ff ff ff ff ff ff
ff 00 00 00 00
R=00040000 H->T CI_TBOOT:  ADP_Booted 00000000
tx: [T=0 L=24] 01 01 00 01 01 00 01 00 00 00 00 00 ff ff ff ff ff ff ff
ff 01 00 01 00
R=00010001 H->T CI_HADP:  ADP_Info 00010001


(arm-elf-gdb -nw -b 115200)
From fnasser@cygnus.com Thu Dec 14 06:46:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: \x03joel.brenner@tchip.com
Cc: gdb@sources.redhat.com, fnasser@gygnus.com
Subject: Re: [Fwd: GDB 5.0 works only at 9600 bps?]
Date: Thu, 14 Dec 2000 06:46:00 -0000
Message-id: <3A38DD4F.95FD75F8@cygnus.com>
References: <3A38D27B.96089DAB@tchip.com>
X-SW-Source: 2000-12/msg00095.html
Content-length: 4764

Joel Brenner wrote:
> 
> Thi is the logfile writed by gdb during the handshake with ANGEL an
> AT91EB40:
> 
> ADP log file opened at Thu Dec 14 14:39:01 2000
> 
> tx: [T=0 L=52] 03 01 00 01 05 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
> ff 01 00 00 00 00 c0 00 00 05 00 00 00 00 c2 01 00 00 e1 00 00 00 96 00
> 00 00 4b 00 00 80 25 00 00
> R=00030005 H->T CI_HBOOT:  ADP_ParamNegotiate 00000001 0000c000 00000005
> 0001c200 0000e100 00009600 00004b00 00002580

That is duplicated.  You must have pasted it twice.

I guess it starts here:

> ADP log file opened at Thu Dec 14 14:49:53 2000
> 
> tx: [T=0 L=52] 03 01 00 01 05 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
> ff 01 00 00 00 00 c0 00 00 05 00 00 00 00 c2 01 00 00 e1 00 00 00 96 00
> 00 00 4b 00 00 80 25 00 00
> R=00030005 H->T CI_HBOOT:  ADP_ParamNegotiate 00000001 0000c000 00000005
> 0001c200 0000e100 00009600 00004b00 00002580

GDB sent the possible speeds it can operate.  The favoured one is the first
(115200)


> rx: [T=0 L=36] 03 02 01 01 05 00 03 80 00 00 00 00 ff ff ff ff ff ff ff
> ff 00 00 00 00 01 00 00 00 00 c0 00 00 00 c2 01 00
> R=80030005 H<-T CI_HBOOT:  ADP_ParamNegotiate 00000000 00000001 0000c000
> 0001c200

The little board says it can do 115200.


> tx: [T=0 L=20] 03 02 00 01 06 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
> ff
> R=00030006 H->T CI_HBOOT:  ADP_LinkCheck

GDB switched to 115200 and pings the board.


> rx: [T=0 L=20] 03 03 02 01 06 00 03 80 00 00 00 00 ff ff ff ff ff ff ff
> ff
> R=80030006 H<-T CI_HBOOT:  ADP_LinkCheck

The board replies.  They are talking at 115200 (but not for long :-(  )

> tx: [T=0 L=24] 03 01 00 01 03 00 03 00 00 00 00 00 ff ff ff ff ff ff ff
> ff 00 00 00 00
> R=00030003 H->T CI_HBOOT:  ADP_Reset 00000000
> rx: [T=0 L=24] 03 01 01 01 03 00 03 80 ff ff ff ff ff ff ff ff ff ff ff
> ff 00 00 00 00
> R=80030003 H<-T CI_HBOOT:  ADP_Reset 00000000
> rx: [T=0 L=215] 04 02 01 01 00 00 04 80 ff ff ff ff ff ff ff ff ff ff ff
> ff f8 00 00 00 f8 07 00 00 01 00 00 00 03 00 00 00 00 00 00 80 01 00 00
> 00 00 00 00 00 a3 00 00 00 41 6e 67 65 6c 20 44 65 62 75 67 20 4d 6f 6e
> 69 74 6f 72 20 28 73 65 72 69 61 6c 29 20 31 2e 30 34 20 28 41 64 76 61
> 6e 63 65 64 20 52 49 53 43 20 4d 61 63 68 69 6e 65 73 20 53 44 54 20 32
> 2e 35 29 20 66 6f 72 20 41 54 39 31 45 42 34 30 20 28 32 2e 30 30 29 0a
> 41 6e 67 65 6c 20 44 65 62 75 67 20 4d 6f 6e 69 74 6f 72 20 72 65 62 75
> 69 6c 74 20 6f 6e 20 41 70 72 20 30 37 20 32 30 30 30 20 61 74 20 31 32
> 3a 34 30 3a 33 31 0a 53 65 72 69 61 6c 20 52 61 74 65 3a 20 31 31 35 32
> 30 30 0a 00
> R=80040000 H<-T CI_TBOOT:  ADP_Booted 000000f8 000007f8 00000001
> 00000003 80000000 00000001 00000000 000000a3 65676e41 6544206c 20677562
> 696e6f4d 20726f74 72657328 296c6169 302e3120 41282034 6e617664 20646563
> 43534952 63614d20 656e6968 44532073 2e322054 66202935 4120726f 45313954
> 20303442 302e3228 410a2930 6c65676e 62654420 4d206775 74696e6f 7220726f
> 69756265 6f20746c 7041206e 37302072 30303220 74612030 3a323120 333a3034
> 65530a31 6c616972 74615220 31203a65 30323531 00000a30
> tx: [T=0 L=24] 04 02 00 01 00 00 04 00 00 00 00 00 ff ff ff ff ff ff ff
> ff 00 00 00 00
> R=00040000 H->T CI_TBOOT:  ADP_Booted 00000000
> tx: [T=0 L=24] 01 01 00 01 01 00 01 00 00 00 00 00 ff ff ff ff ff ff ff
> ff 01 00 01 00

All the above mesages, on channels 3 and 4 (CI_HBOOT and CI_TBOOT) were
supposedly at 115200.



> R=00010001 H->T CI_HADP:  ADP_Info 00010001
> 

From this point on communication goes (mainly) through channels 1 and 2
(i.e. CI_HADP and CI_TADP).

Here is the board bug.  It seems that messages sent by the host on channel 1
are not received or the response is sent at a different speed or whatever
(I don't have the instruments to find out).

My theory is that the board may have received this message but is switching the
serial line back to 9600 when sending data through channel 2.  This would explain
why this works when we keep the speed at 9600 -- as GDB is still at 9600 it will
get the reply to the ADP_Info RPC all right.

Don't ask me how the other debugger you've mentioned is able to survive this 
condition.  The client RDI protocol we use in GDB was given to us by ARM and it
adheres strictly to the protocol specs (which I have printed here). 


One possible way to test this theory would be changing GDB's speed back to 9600
after sending the ADP_INFO packet.  If it still does not work, change it before
sending it.  But I don't have time to do this now.


Why don't you post this to  aeb@arm.com  ?   (Our board's mailing list)

That seems to be the appropriate list.  GDB swtiches speed OK with all other boards.


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From benoit.millot@cstelecom.com Thu Dec 14 07:30:00 2000
From: "Benoit MILLOT" <benoit.millot@cstelecom.com>
To: GDB <gdb@sourceware.cygnus.com>
Subject: Fatal Error on making GDB on host sparc with target m68k !?
Date: Thu, 14 Dec 2000 07:30:00 -0000
Message-id: <3A38E87B.A770FF19@cstelecom.com>
X-SW-Source: 2000-12/msg00096.html
Content-length: 1672

Hello,
In the past, I have already made gdb-5.0 with these command :

    configure --host=sparc-sun-solaris2.6 --target=m68k-coff
--prefix=/home/millot/sparc
    make
    make install

and it works fine.

Now, the make command displays :

    -I../../../gdb-5.0_CS/gdb/../bfd
-I../../../gdb-5.0_CS/gdb/../include  -I../intl
-I../../../gdb-5.0_CS/gdb/../intl
    -I../../../gdb-5.0_CS/gdb/tui   -DUSE_INCLUDED_REGEX
../../../gdb-5.0_CS/gdb/monitor.c
    make: Fatal error: Don't know how to make target `remote-est.o'
    Current working directory
/home/millot/develop/gdbdev/build_CS1/m68k/gdb
    *** Error code 1
    make: Fatal error: Command failed for target `all-gdb'

With host=i686-pc-linux-gnu , no error occurs.

I have made diff of the config.status ans config.cache and tools which
are used, seems to be same.
I doesn't know if tools have changed?
So someone have an idea ?

I make an add on Makefile.in in /gdb-5.0/gdb like that :
    # FIXME: for the m68k target B Millot 2000-12-14
    remote-est.o: remote-est.c $(defs_h) $(gdbcore_h) target.h \
             monitor.h serial.h
    cpu32bug-rom.o: cpu32bug-rom.c $(defs_h) $(gdbcore_h) target.h \
             monitor.h serial.h
    abug-rom.o: abug-rom.c $(defs_h) $(gdbcore_h) target.h \
             monitor.h serial.h
    dbug-rom.o: dbug-rom.c  $(defs_h) $(gdbcore_h) target.h \
             monitor.h serial.h
    # end FIXME.
That works but i want to knows

    1 if it is the good way
    2 why this is needed now and not before ?
    3 why the generation for host GNU/Linux doesn't need "file
dependances"

Thanks a lot.

                                                                Benoît