Re: Jeeni & ARM720T with GDB

[Grant Edwards <grante@visi.com>]

On Mon, Nov 20, 2000 at 05:38:21PM -0600, Michael Leibowitz wrote:

> > The "load" works OK?
> 
> Yeah

Do the load addresses and start addresses printed by the "load"
command look right?

-- 
Grant Edwards
grante@visi.com
From hjl@valinux.com Mon Nov 20 15:59:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: binutils@sourceware.cygnus.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 15:59:00 -0000
Message-id: <20001120155917.A15923@valinux.com>
X-SW-Source: 2000-11/msg00211.html
Content-length: 4665

ELFOSABI_MONTEREY has been replaced by ELFOSABI_AIX. I have checked in
patches to change all ELFOSABI_MONTEREY to ELFOSABI_AIX.

BTW, ELFOSABI_NONE, ELFOSABI_HPUX, ELFOSABI_NETBSD, ELFOSABI_LINUX,
ELFOSABI_HURD, ELFOSABI_SOLARIS, ELFOSABI_AIX, ELFOSABI_IRIX,
ELFOSABI_FREEBSD, ELFOSABI_TRU64, ELFOSABI_MODESTO and ELFOSABI_OPENBSD
will be moved from psABI to gABI. The first 128 entries in EI_OSABI
will be reserved for gABI and the last 28 entries will be for psABI. I
saw

#define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */
#define ELFOSABI_ARM   97               /* ARM */

in include/elf/common.h. They will violate the new gABI.

BTW, the EI_OSABI byte is used to tell how to interpret those fields
and values which are not defined by gABI nor psABI. It is not to tell
on which platform the binary is targeted. I am not sure if ELFOSABI_ARM
and ELFOSABI_STANDALONE are proper uses for this field. Should we fix
them?


-- 
H.J. Lu (hjl@valinux.com)
---
Index: binutils/ChangeLog
===================================================================
RCS file: /cvs/src/src/binutils/ChangeLog,v
retrieving revision 1.222
diff -u -p -r1.222 ChangeLog
--- ChangeLog	2000/11/19 20:57:42	1.222
+++ ChangeLog	2000/11/20 23:39:37
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* readelf.c (get_osabi_name): Change ELFOSABI_MONTEREY to
+	ELFOSABI_AIX.
+
 2000-11-17  Richard Henderson  <rth@redhat.com>
 
 	* readelf.c (display_debug_lines): Adjust last change to
Index: binutils/readelf.c
===================================================================
RCS file: /cvs/src/src/binutils/readelf.c,v
retrieving revision 1.72
diff -u -p -r1.72 readelf.c
--- readelf.c	2000/11/19 20:57:42	1.72
+++ readelf.c	2000/11/20 23:39:45
@@ -2087,7 +2087,7 @@ get_osabi_name (osabi)
     case ELFOSABI_LINUX:      return _("UNIX - Linux");
     case ELFOSABI_HURD:       return _("GNU/Hurd");
     case ELFOSABI_SOLARIS:    return _("UNIX - Solaris");
-    case ELFOSABI_MONTEREY:   return _("UNIX - Monterey");
+    case ELFOSABI_AIX:        return _("UNIX - AIX");
     case ELFOSABI_IRIX:       return _("UNIX - IRIX");
     case ELFOSABI_FREEBSD:    return _("UNIX - FreeBSD");
     case ELFOSABI_TRU64:      return _("UNIX - TRU64");
Index: gdb/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.789
diff -u -p -r1.789 ChangeLog
--- ChangeLog	2000/11/20 20:33:52	1.789
+++ ChangeLog	2000/11/20 23:39:52
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* ia64-tdep.c (gdbarch_tdep): Change reference from
+	ELFOSABI_MONTEREY to ELFOSABI_AIX.
+
 2000-11-20  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
 
 	* c-valprint.c (print_function_pointer_address):  New function
Index: gdb/ia64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ia64-tdep.c,v
retrieving revision 1.10
diff -u -p -r1.10 ia64-tdep.c
--- ia64-tdep.c	2000/11/08 04:12:40	1.10
+++ ia64-tdep.c	2000/11/20 23:39:55
@@ -226,7 +226,7 @@ struct frame_extra_info
 struct gdbarch_tdep
   {
     int os_ident;	/* From the ELF header, one of the ELFOSABI_
-                           constants: ELFOSABI_LINUX, ELFOSABI_MONTEREY,
+                           constants: ELFOSABI_LINUX, ELFOSABI_AIX,
 			   etc. */
     CORE_ADDR (*sigcontext_register_address) (CORE_ADDR, int);
     			/* OS specific function which, given a frame address
Index: include/elf/ChangeLog
===================================================================
RCS file: /cvs/src/src/include/elf/ChangeLog,v
retrieving revision 1.71
diff -u -p -r1.71 ChangeLog
--- ChangeLog	2000/11/16 22:48:14	1.71
+++ ChangeLog	2000/11/20 23:39:58
@@ -1,3 +1,8 @@
+2000-11-20  H.J. Lu  <hjl@gnu.org>
+
+	* common.h (ELFOSABI_MONTEREY): Renamed to ...
+	(ELFOSABI_AIX): This.
+
 2000-11-16  Richard Henderson  <rth@redhat.com>
 
 	Update relocations per August psABI docs.
Index: include/elf/common.h
===================================================================
RCS file: /cvs/src/src/include/elf/common.h,v
retrieving revision 1.23
diff -u -p -r1.23 common.h
--- common.h	2000/07/20 15:44:56	1.23
+++ common.h	2000/11/20 23:39:59
@@ -64,7 +64,7 @@ Foundation, Inc., 59 Temple Place - Suit
 #define ELFOSABI_LINUX  3       /* GNU/Linux */
 #define ELFOSABI_HURD   4       /* GNU/Hurd */
 #define ELFOSABI_SOLARIS 6      /* Solaris */
-#define ELFOSABI_MONTEREY 7     /* Monterey */
+#define ELFOSABI_AIX    7       /* AIX */
 #define ELFOSABI_IRIX   8       /* IRIX */
 #define ELFOSABI_FREEBSD 9      /* FreeBSD */
 #define ELFOSABI_TRU64  10      /* TRU64 UNIX */
From Fabrice_Gautier@sdesigns.com Mon Nov 20 16:12:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "'insight@sources.redhat.com'" <insight@sources.redhat.com>
Cc: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 16:12:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015032@EMAIL1>
X-SW-Source: 2000-11/msg00212.html
Content-length: 1283

Hi,

I think i found why it failed. The following patch seems to have a good
effect:

--- gdb/linespec.c~ Fri Nov 10 15:02:56 2000
+++ gdb/linespec.c  Mon Nov 20 15:13:43 2000
@@ -37,7 +37,7 @@

 extern char *operator_chars (char *, char **);

-extern char *no_symtab_msg;
+extern char no_symtab_msg[];

 /* Prototypes for local functions */

The no_symtab_msg is defined as char no_symtab_msg[] in an other file, and
not as 
char *no_symtab_msg.

I think there might be a few other place where this mistake could have been
made but i didn't saw any around that one.

By the way this seems more like a gdb thing than a insight thing, but it was
somehow triggered when using the gui.

Thanks

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Monday, November 20, 2000 2:19 PM
> To: 'insight@sources.redhat.com'
> Subject: RE: Buil problem
> 
> 
> Hi,
> 
> Attached is a call stack I obtained with gdb,
> 
> If it helps find the problem.
> 
> Thanks
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Subject: RE: Buil problem
> > 
> > 
> > Using the latest snapshot i didn't have any problem building. 
> > But insight
> > still crash unless I use -nw.
> > 
> > Thanks
>  
> 
> 
From kevinb@cygnus.com Mon Nov 20 16:26:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: "H . J . Lu" <hjl@valinux.com>, binutils@sourceware.cygnus.com
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 16:26:00 -0000
Message-id: <1001121002613.ZM18358@ocotillo.lan>
References: <20001120155917.A15923@valinux.com> <hjl@valinux.com>
X-SW-Source: 2000-11/msg00213.html
Content-length: 377

On Nov 20,  3:59pm, H . J . Lu wrote:

> BTW, the EI_OSABI byte is used to tell how to interpret those fields
> and values which are not defined by gABI nor psABI. It is not to tell
> on which platform the binary is targeted. [...]

What is the proper method for determining the target platform?

(I know how to do it if it's linked against glibc, but not
otherwise...)

Kevin
From fnasser@cygnus.com Mon Nov 20 16:39:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 16:39:00 -0000
Message-id: <3A19C413.519904F1@cygnus.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015032@EMAIL1>
X-SW-Source: 2000-11/msg00214.html
Content-length: 1992

This fix is already in the current sources.  It was broken for a few hours
and it is very unfortunate you've got it during that window of time.

I inadvertently broke this when splitting a file so at least you have
someone to blame ;-)

BTW, when using the latest sources from cvs and encountering a build problem,
always try to do a "cvs update".  Any glitch like this is normally fixed
quickly.

Sorry about all the trouble.

Fernando



Fabrice Gautier wrote:
> 
> Hi,
> 
> I think i found why it failed. The following patch seems to have a good
> effect:
> 
> --- gdb/linespec.c~ Fri Nov 10 15:02:56 2000
> +++ gdb/linespec.c  Mon Nov 20 15:13:43 2000
> @@ -37,7 +37,7 @@
> 
>  extern char *operator_chars (char *, char **);
> 
> -extern char *no_symtab_msg;
> +extern char no_symtab_msg[];
> 
>  /* Prototypes for local functions */
> 
> The no_symtab_msg is defined as char no_symtab_msg[] in an other file, and
> not as
> char *no_symtab_msg.
> 
> I think there might be a few other place where this mistake could have been
> made but i didn't saw any around that one.
> 
> By the way this seems more like a gdb thing than a insight thing, but it was
> somehow triggered when using the gui.
> 
> Thanks
> 
> > -----Original Message-----
> > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > Sent: Monday, November 20, 2000 2:19 PM
> > To: 'insight@sources.redhat.com'
> > Subject: RE: Buil problem
> >
> >
> > Hi,
> >
> > Attached is a call stack I obtained with gdb,
> >
> > If it helps find the problem.
> >
> > Thanks
> >
> > > -----Original Message-----
> > > From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> > > Subject: RE: Buil problem
> > >
> > >
> > > Using the latest snapshot i didn't have any problem building.
> > > But insight
> > > still crash unless I use -nw.
> > >
> > > Thanks
> >
> >
> >

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From hjl@valinux.com Mon Nov 20 16:39:00 2000
From: "H . J . Lu" <hjl@valinux.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: binutils@sourceware.cygnus.com, GDB <gdb@sourceware.cygnus.com>
Subject: Re: Patches to change ELFOSABI_MONTEREY to ELFOSABI_AIX.
Date: Mon, 20 Nov 2000 16:39:00 -0000
Message-id: <20001120163940.B17290@valinux.com>
References: <20001120155917.A15923@valinux.com> <hjl@valinux.com> <1001121002613.ZM18358@ocotillo.lan>
X-SW-Source: 2000-11/msg00215.html
Content-length: 879

On Mon, Nov 20, 2000 at 05:26:13PM -0700, Kevin Buettner wrote:
> On Nov 20,  3:59pm, H . J . Lu wrote:
> 
> > BTW, the EI_OSABI byte is used to tell how to interpret those fields
> > and values which are not defined by gABI nor psABI. It is not to tell
> > on which platform the binary is targeted. [...]
> 
> What is the proper method for determining the target platform?
> 
> (I know how to do it if it's linked against glibc, but not
> otherwise...)
> 

There is no easy way to tell, at least not from the EI_OSABI byte.
That is one reason why glibc did what it did. I was told people thought
about changing EI_OSABI to something else because of the confusion it
might lead to. But they decided against it.

BTW, in the modern world, there should be no static binaries. You can
tell which target a dynamic binary is for by checking PT_INTERP.


-- 
H.J. Lu (hjl@valinux.com)
From Fabrice_Gautier@sdesigns.com Mon Nov 20 18:22:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Fernando Nasser' <fnasser@cygnus.com>
Cc: "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 18:22:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1>
X-SW-Source: 2000-11/msg00216.html
Content-length: 695

> -----Original Message-----
> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
> Sent: Monday, November 20, 2000 4:39 PM
> To: Fabrice Gautier
> Cc: 'insight@sources.redhat.com'; GDB (E-mail)
> Subject: Re: Buil problem
> 
> 
> This fix is already in the current sources.  It was broken 
> for a few hours
> and it is very unfortunate you've got it during that window of time.

In fact it came from the latest snapshot... Unfortunate the snapshot was
taken during that window of time...

But i still have a problem, insight won't start in background. If you do 
"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
From cgf@redhat.com Mon Nov 20 18:56:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "'Fernando Nasser'" <fnasser@cygnus.com>, "'insight@sources.redhat.com'" <insight@sources.redhat.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 18:56:00 -0000
Message-id: <20001120215543.C3169@redhat.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1>
X-SW-Source: 2000-11/msg00217.html
Content-length: 644

On Mon, Nov 20, 2000 at 06:21:24PM -0800, Fabrice Gautier wrote:
>> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
>> 
>> This fix is already in the current sources.  It was broken 
>> for a few hours
>> and it is very unfortunate you've got it during that window of time.
>
>In fact it came from the latest snapshot... Unfortunate the snapshot was
>taken during that window of time...
>
>But i still have a problem, insight won't start in background. If you do 
>"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 

I believe that this has always been a problem with insight.  You can't
start it in the background.

cgf
From Fabrice_Gautier@sdesigns.com Mon Nov 20 19:09:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "'insight@sources.redhat.com'" <insight@sources.redhat.com>
Cc: 'Fernando Nasser' <fnasser@cygnus.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: RE: Buil problem
Date: Mon, 20 Nov 2000 19:09:00 -0000
Message-id: <B1F6452C89AFD411AE0800A0CC734C23015035@EMAIL1>
X-SW-Source: 2000-11/msg00218.html
Content-length: 691

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Subject: Re: Buil problem
> 
> >
> >But i still have a problem, insight won't start in 
> >background. If you do 
> >"i386-elf-gdb &"  the progran stop and i can have it back with "fg". 
> 
> I believe that this has always been a problem with insight.  You can't
> start it in the background.

I believe (no: i'm sure) I did it many times with 5.0 + patches from eCos
website.

I didn't applied the from-the-eCos-website patches to my recent build cause
it seems that they were already applied in the cvs/latest snapshot but maybe
I overlooked something.


-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
From fnasser@cygnus.com Mon Nov 20 19:10:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: insight@sources.redhat.com
Cc: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>, "GDB (E-mail)" <gdb@sources.redhat.com>
Subject: Re: Buil problem
Date: Mon, 20 Nov 2000 19:10:00 -0000
Message-id: <3A19E781.11269FC1@cygnus.com>
References: <B1F6452C89AFD411AE0800A0CC734C23015034@EMAIL1> <20001120215543.C3169@redhat.com>
X-SW-Source: 2000-11/msg00219.html
Content-length: 872

Christopher Faylor wrote:
> 
> On Mon, Nov 20, 2000 at 06:21:24PM -0800, Fabrice Gautier wrote:
> >> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
> >>
> >> This fix is already in the current sources.  It was broken
> >> for a few hours
> >> and it is very unfortunate you've got it during that window of time.
> >
> >In fact it came from the latest snapshot... Unfortunate the snapshot was
> >taken during that window of time...
> >
> >But i still have a problem, insight won't start in background. If you do
> >"i386-elf-gdb &"  the progran stop and i can have it back with "fg".
> 
> I believe that this has always been a problem with insight.  You can't
> start it in the background.
> 

Yes, it is a known problem.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From d_iftikhar@hotmail.com Mon Nov 20 22:23:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: mleibowi@crystal.cirrus.com, fnasser@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 22:23:00 -0000
Message-id: <F170WerOc0Ne0PaLI9m00000541@hotmail.com>
X-SW-Source: 2000-11/msg00220.html
Content-length: 1424

>From: Michael Leibowitz <mleibowi@crystal.cirrus.com>
>Reply-To: mleibowi@crystal.cirrus.com
>To: Fernando Nasser <fnasser@cygnus.com>
>CC: danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
>Subject: Re: Jeeni & ARM720T with GDB
>Date: Mon, 20 Nov 2000 11:04:14 -0600
>
>When I try that, I get an error message:
>
>Continuing.
>RDI_execute: a miscellaneous type of error
>
>Program received signal SIGTERM, Terminated.
>?? () at setup.S:4
>4		B	Reset_Handler
>Current language:  auto; currently asm
>
>using gdb 5.0 (insight w/ -nw) and 7211 eval board.
>
>Any ideas?
>
>On Mon, 20 Nov 2000 10:48:14 Fernando Nasser wrote:
> > The sequence of commands you should use is:
> >
> > file <exec>
> > target rdi e=....
> > load
> > break <somewhere>
> > cont
> >
> >
> > Don't use the load command argument.
>
******************

   Well , i tried to use the above commands and was able to download 
successfully . But after i set break point and do continue , everything 
seems to hang .
Any guesses what is going wrong now .
the rdiromatzero command for EP7211 board should be set at 0 or 1 ??
i am using insight 5.0 .

  do we need to specifically download some program for reset and all those 
things which Grant has told .

regards
danish.


_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com