* Re: Jeeni & ARM720T with GDB
[not found] <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com>
@ 2000-11-20 8:48 ` Fernando Nasser
[not found] ` <20001120110414.B23797@spanky>
0 siblings, 1 reply; 5+ messages in thread
From: Fernando Nasser @ 2000-11-20 8:48 UTC (permalink / raw)
To: danish iftikhar; +Cc: gdb
The sequence of commands you should use is:
file <exec>
target rdi e=....
load
break <somewhere>
cont
Don't use the load command argument.
Fernando
danish iftikhar wrote:
>
> Hi
> I am trying to use Jeeni EMbedded Ice to connect from my linux host
> running GDB to Cirrus Logic EP7211 board .
> The board uses ARM720T processor , due to which i have set the same
> configuration in Jeeni .
> Then i tried to connect to target by using target rdi e=IP_ADDR ;
> ( as i tried using ethernet interface ) . It then said connected to target
> ..something..something .
> But when i give the load (filename) , it does'nt do anything ..
> once it said "you can't do that when your target is exec" , i gave the
> target rdi command again and tried to download & then it hanged .
>
> Can anybody explain what is happening...do i need to do anything else for
> downloading the program .
>
> PS: i have set the appropriate endianness also .
>
> regards
> danish.
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com .
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From mleibowi@crystal.cirrus.com Mon Nov 20 09:01:00 2000
From: Michael Leibowitz <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 09:01:00 -0000
Message-id: <20001120110414.B23797@spanky>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com>
X-SW-Source: 2000-11/msg00203.html
Content-length: 502
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Jeeni & ARM720T with GDB
[not found] ` <20001120110414.B23797@spanky>
@ 2000-11-20 9:18 ` Fernando Nasser
[not found] ` <20001120162925.B11863@visi.com>
1 sibling, 0 replies; 5+ messages in thread
From: Fernando Nasser @ 2000-11-20 9:18 UTC (permalink / raw)
To: mleibowi; +Cc: danish iftikhar, gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9863 bytes --]
Michael Leibowitz wrote:
>
> 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?
>
It can be the way you compiled/linked your program or a series of
other reasons. There is not much information above.
Maybe you should post pieces of console output with the relevant
information (the output of "gcc -v", your compilation command and
any messages printed by gcc, etc).
BTW, which host are you running gdb on? Which OS version, libraries...
If I am not mistaken, there were a series of fixes and improvements
to GDB RDI after 5.0 came out. I am not sure that they can make any
difference to your case, but maybe you should consider switching to
more recent sources.
Fernando
> 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.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From grante@visi.com Mon Nov 20 14:25:00 2000
From: Grant Edwards <grante@visi.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 14:25:00 -0000
Message-id: <20001120162802.A11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com>
X-SW-Source: 2000-11/msg00205.html
Content-length: 755
On Mon, Nov 20, 2000 at 04:48:14PM +0000, 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.
Why not?
It works fine for me. The macro I use to load an ELF object
file is:
define reload
resetcpu
delete
symbol-file
symbol-file $arg0
load $arg0
break *0x00
break *0x04
break *0x08
break *0x0c
break *0x10
break *0x14
# IRQ at 0x18 is used
break *0x1c
end
After a "reload" then I do "cont" after optionally setting more
breakpoints.
The "resetcpu" command at the top is another macro that resets
a bunch of peripheral chips and puts them into a known state.
--
Grant Edwards
grante@visi.com
From grante@visi.com Mon Nov 20 14:27:00 2000
From: Grant Edwards <grante@visi.com>
To: Michael Leibowitz <mleibowi@crystal.cirrus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 14:27:00 -0000
Message-id: <20001120162925.B11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky>
X-SW-Source: 2000-11/msg00206.html
Content-length: 436
On Mon, Nov 20, 2000 at 11:04:14AM -0600, Michael Leibowitz wrote:
> 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?
The "load" works OK?
--
Grant Edwards
grante@visi.com
From grante@visi.com Mon Nov 20 14:28:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: mleibowi@crystal.cirrus.com, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 14:28:00 -0000
Message-id: <20001120163048.C11863@visi.com>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky> <3A195CAA.ED939698@cygnus.com>
X-SW-Source: 2000-11/msg00207.html
Content-length: 814
On Mon, Nov 20, 2000 at 05:17:30PM +0000, Fernando Nasser wrote:
> It can be the way you compiled/linked your program or a series of
> other reasons. There is not much information above.
> Maybe you should post pieces of console output with the relevant
> information (the output of "gcc -v", your compilation command and
> any messages printed by gcc, etc).
>
> BTW, which host are you running gdb on? Which OS version, libraries...
>
> If I am not mistaken, there were a series of fixes and improvements
> to GDB RDI after 5.0 came out. I am not sure that they can make any
> difference to your case, but maybe you should consider switching to
> more recent sources.
Most of the changes had to do with Insight GUI issues, but it
couldn't hurt to use a recent snapshot.
--
Grant Edwards
grante@visi.com
From Stephane.Carrez@worldnet.fr Mon Nov 20 14:46:00 2000
From: Stephane Carrez <Stephane.Carrez@worldnet.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb@sources.redhat.com
Subject: Re: RFC: Components
Date: Mon, 20 Nov 2000 14:46:00 -0000
Message-id: <3A19B7F2.665348DC@worldnet.fr>
References: <3A0B3556.510B850A@cygnus.com> <3A19491E.E2FDB7FB@cygnus.com>
X-SW-Source: 2000-11/msg00208.html
Content-length: 3730
Hi!
Andrew Cagney a écrit :
>
> Fernando Nasser wrote:
> >
> > We got a submission from a contributor that would like to add the following
> > facility to GDB, which can be useful when debugging Operating Systems.
> >
> > An operating system can comprise of several components, each of them
> > linked separately. When doing system debug, the symbols of all the
> > OS components are loaded into GDB. Once loaded, GDB has several symbol
> > files that it uses to search for symbols and debugging information.
>
> (Like J.T. I'm not also sure about the word component)
So do I. But I had no better name to propose/use...
>
> I think this can be broken down into several problems/issues.
>
> GDB is (eventually :-) going to get support for multiple
> processes/actors/.... Such proceses can probably be categorized into
> two classes:
>
> o VM
>
> Where separate processes have
> independant address spaces.
>
> Examples include most modern
> OS's along with UNIX and Linux.
>
> o no-vm
>
> Where separate processes share
> a common address space.
>
> Examples of this would include
> uLinux and MINIX/68k.
>
> I think an extention to GDB's SAL (linespec) syntax needs to be clearly
> defined so that it will be possible to identify the process that a
> symbol belongs to. The exact syntax will likely need more thought
> although the proposal is probably a good starting point. It is more
> natural to use the target OS's process names and that is a departure
> from the current GDB convention which, in the case of threads, adopted
> arbitrary internal numbers.
Yes, but using the target OS's process name is more difficult. The so-called
component may not refer to a process. It can of course, but it can also
represent some code that is loaded.
Doing that requires more changes in Gdb too, since this is target specific.
We also need a way to attach some target specific name to the symtab.
>
> Depending on the kernel, it may be possible to unwind a stack back
> through the user->kernel system call. On such systems, the stack dump
> should clearly identify the process that the stack frames belong to. On
> OSs that use an indirect call to get into the kernel, this is pretty
> much a no-brainer. On OSs that context switch on entry into the kernel,
> this is more complex Something a bit like the code to unwind past a
> single handler would be needed.
Stack unwinding does not work in gdb when you cross a trap/exception handler
It would be good to teach that in Gdb. But it's not easy...
>
> At a more general level, I don't have any real reservations about the
> proposed functionality (I've encountered a number of embedded systems
> where I've had to use smoke and mirrors to get around just this
> problem). The concerns I have are related to the details of the
> implementation and how well the actual changes fit in with the broad
> strategy of evolving GDB into a multi-processor debugger.
>
> Andrew
Using the basename of the symbol file was very simple. I guess it's possible
to use another transformation operation that produces such short printable string.
Stephane
-----------------------------------------------------------------------
Home Office
E-mail: stcarrez@worldnet.fr Stephane.Carrez@sun.com
WWW: http://home.worldnet.fr/stcarrez http://www.sun.com
Mail: 17, rue Foucher Lepelletier 6, avenue Gustave Eiffel
92130 Issy Les Moulineaux 78182 Saint Quentin en Yvelines
France
From mleibowi@crystal.cirrus.com Mon Nov 20 15:34:00 2000
From: Michael Leibowitz <mleibowi@crystal.cirrus.com>
To: Grant Edwards <grante@visi.com>
Cc: Michael Leibowitz <mleibowi@crystal.cirrus.com>, Fernando Nasser <fnasser@cygnus.com>, danish iftikhar <d_iftikhar@hotmail.com>, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Mon, 20 Nov 2000 15:34:00 -0000
Message-id: <20001120173821.B24131@spanky>
References: <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com> <3A1955CE.2A4280C8@cygnus.com> <20001120110414.B23797@spanky> <20001120162925.B11863@visi.com>
X-SW-Source: 2000-11/msg00209.html
Content-length: 150
On Mon, 20 Nov 2000 16:29:25 Grant Edwards wrote:
> On Mon, Nov 20, 2000 at 11:04:14AM -0600, Michael Leibowitz wrote:
> The "load" works OK?
Yeah
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Jeeni & ARM720T with GDB
[not found] ` <20001120173821.B24131@spanky>
@ 2000-11-20 15:43 ` Grant Edwards
0 siblings, 0 replies; 5+ messages in thread
From: Grant Edwards @ 2000-11-20 15:43 UTC (permalink / raw)
To: Michael Leibowitz; +Cc: Fernando Nasser, danish iftikhar, gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Jeeni & ARM720T with GDB
[not found] <F2693AmsfGdMNFmWAFs00000388@hotmail.com>
@ 2000-11-22 6:36 ` Grant Edwards
0 siblings, 0 replies; 5+ messages in thread
From: Grant Edwards @ 2000-11-22 6:36 UTC (permalink / raw)
To: danish iftikhar; +Cc: fnasser, gdb
On Wed, Nov 22, 2000 at 10:35:04AM -0000, danish iftikhar wrote:
> After load Pc shows the address : 0x8060
>
> The start uo code is :
> (gdb) x/30i $pc
> 0x8060 <warm_reset>: mrs r7, cpsr
> 0x8064 <warm_reset+4>: and r7, r7, #31 ; 0x1f
> 0x8068 <warm_reset+8>: cmp r7, #19 ; 0x13
> 0x806c <warm_reset+12>: beq 0x80a0 <start>
That looks right.
> i am not able to do step or cont but using stepi i went through this
> startup function . It seems to loop around between 0x815c & 0x8164 and is
> not going ahead of that .
> the code at this address is as follows :
>
> 0x8154 <start+180>: cmp r1, r2
> - 0x8158 <start+184>: beq 0x8168 <start+200>
> - 0x815c <start+188>: str r0, [r1], #4
> - 0x8160 <start+192>: cmp r1, r2
> - 0x8164 <start+196>: bne 0x815c <start+188>
> - 0x8168 <start+200>: bl 0x1f194 <hal_hardware_init>
> - 0x816c <start+204>: bl 0x1ee10
> <cyg_hal_invoke_constructors>
> - 0x8170 <start+208>: bl 0x1f358 <cyg_start>
It looks to me like the debugger and emulator are working fine.
The loop you're looking at is zeroing out the bss section. R2
should contain the address of the end of bss, and R1 should
start at the beginning of bss and increment through the whole
section. This loop will probably execute tens of thousands of
times, so you can get pretty bored doing a stepi...
Do the addresses in R1 and R2 correspond to your bss section?
Can you set a breakpoint immediately following the loop and do
a cont?
--
Grant Edwards
grante@visi.com
From jimb@zwingli.cygnus.com Wed Nov 22 07:21:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap (again)
Date: Wed, 22 Nov 2000 07:21:00 -0000
Message-id: <np1yw43ud3.fsf@zwingli.cygnus.com>
References: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00229.html
Content-length: 86
> Comments?
It looks reasonable. I'd say, give it a try and see what annoys people.
From taylor@cygnus.com Wed Nov 22 08:54:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: pathmap semantics issues
Date: Wed, 22 Nov 2000 08:54:00 -0000
Message-id: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00230.html
Content-length: 402
Okay, here's some questions concerning how pathmap should behave:
. should it translate all paths? Or just some paths? If some, which?
Source paths? Others? That is, should it be consulted when looking
for sources?, objects?, executables?, and shared objects?
. should it be searched instead of the existing path? Or in addition?
If in addition, which should be searched first?
Do people care?
From cgf@redhat.com Wed Nov 22 08:58:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: Re: pathmap semantics issues
Date: Wed, 22 Nov 2000 08:58:00 -0000
Message-id: <20001122115802.B7346@redhat.com>
References: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00231.html
Content-length: 769
On Wed, Nov 22, 2000 at 11:53:38AM -0500, David Taylor wrote:
>Okay, here's some questions concerning how pathmap should behave:
>
>. should it translate all paths? Or just some paths? If some, which?
>Source paths? Others? That is, should it be consulted when looking
>for sources?, objects?, executables?, and shared objects?
>
>. should it be searched instead of the existing path? Or in addition?
>If in addition, which should be searched first?
>
>Do people care?
I would think that it should be "all paths". If you've gone to the
effort of issuing the pathmap command then it must be for the reason
that you don't have the specific path on your system and need to
translate it. So, using the pathmap translation for everything would
make sense, IMO.
cgf
From msnyder@redhat.com Wed Nov 22 09:17:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap semantics issues
Date: Wed, 22 Nov 2000 09:17:00 -0000
Message-id: <3A1BFFAF.1E9A@redhat.com>
References: <200011221653.LAA22540@texas.cygnus.com>
X-SW-Source: 2000-11/msg00232.html
Content-length: 550
David Taylor wrote:
>
> Okay, here's some questions concerning how pathmap should behave:
>
> . should it translate all paths? Or just some paths? If some, which?
> Source paths? Others? That is, should it be consulted when looking
> for sources?, objects?, executables?, and shared objects?
>
> . should it be searched instead of the existing path? Or in addition?
> If in addition, which should be searched first?
I hope it won't interfere with the path for searching for
shared libraries. I've just spent some effort sanifying that...
From ac131313@cygnus.com Wed Nov 22 20:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: gdb@gnu.org Discussion
Date: Wed, 22 Nov 2000 20:55:00 -0000
Message-id: <3A1CA166.A24792EF@cygnus.com>
X-SW-Source: 2000-11/msg00233.html
Content-length: 148
People on this mailing list should be aware of the discussion:
http://sources.redhat.com/ml/overseers/2000-q4/threads.html#00214
sorry,
Andrew
From d_iftikhar@hotmail.com Wed Nov 22 23:15:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: grante@visi.com
Cc: fnasser@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Jeeni & ARM720T with GDB
Date: Wed, 22 Nov 2000 23:15:00 -0000
Message-id: <F285Ca3Eky00sp0yx2p0000234c@hotmail.com>
X-SW-Source: 2000-11/msg00234.html
Content-length: 3399
Hi
i went through the code and checked the addresses of bss as well as
other sections and they are perfectly o.k.
ya , grant , it's zeroing the bss address only and i was able to come out
of that loop .
where it stucks is in <cyg_hal_invoke_constructors> : take a look at code
below :
> > 0x8154 <start+180>: cmp r1, r2
> > - 0x8158 <start+184>: beq 0x8168 <start+200>
> > - 0x815c <start+188>: str r0, [r1], #4
> > - 0x8160 <start+192>: cmp r1, r2
> > - 0x8164 <start+196>: bne 0x815c <start+188>
> > - 0x8168 <start+200>: bl 0x1f194
><hal_hardware_init>
> > - 0x816c <start+204>: bl 0x1ee10
<cyg_hal_invoke_constructors>
> > > > - 0x8170 <start+208>: bl 0x1f358 <cyg_start>
things seem to work perfectly fine for h/w initialisation .
i wonder whether some special options have to be configured in ecos build
to make it work. i have a basic doubt ..how the diagnostic output is handled
.
i don't think that jeeni will be able to send it back to console ..
or will connecting through the serial port work .
is the diag printf 's are the one causing it to hang.
thanks
danish.
>From: Grant Edwards <grante@visi.com>
>To: danish iftikhar <d_iftikhar@hotmail.com>
>CC: fnasser@cygnus.com, gdb@sourceware.cygnus.com
>Subject: Re: Jeeni & ARM720T with GDB
>Date: Wed, 22 Nov 2000 08:39:21 -0600
>
>On Wed, Nov 22, 2000 at 10:35:04AM -0000, danish iftikhar wrote:
>
> > After load Pc shows the address : 0x8060
> >
> > The start uo code is :
> > (gdb) x/30i $pc
> > 0x8060 <warm_reset>: mrs r7, cpsr
> > 0x8064 <warm_reset+4>: and r7, r7, #31 ; 0x1f
> > 0x8068 <warm_reset+8>: cmp r7, #19 ; 0x13
> > 0x806c <warm_reset+12>: beq 0x80a0 <start>
>
>That looks right.
>
> > i am not able to do step or cont but using stepi i went through this
> > startup function . It seems to loop around between 0x815c & 0x8164 and
>is
> > not going ahead of that .
> > the code at this address is as follows :
> >
> > 0x8154 <start+180>: cmp r1, r2
> > - 0x8158 <start+184>: beq 0x8168 <start+200>
> > - 0x815c <start+188>: str r0, [r1], #4
> > - 0x8160 <start+192>: cmp r1, r2
> > - 0x8164 <start+196>: bne 0x815c <start+188>
> > - 0x8168 <start+200>: bl 0x1f194
><hal_hardware_init>
> > - 0x816c <start+204>: bl 0x1ee10
> > <cyg_hal_invoke_constructors>
> > - 0x8170 <start+208>: bl 0x1f358 <cyg_start>
>
>It looks to me like the debugger and emulator are working fine.
>The loop you're looking at is zeroing out the bss section. R2
>should contain the address of the end of bss, and R1 should
>start at the beginning of bss and increment through the whole
>section. This loop will probably execute tens of thousands of
>times, so you can get pretty bored doing a stepi...
>
>Do the addresses in R1 and R2 correspond to your bss section?
>
>Can you set a breakpoint immediately following the loop and do
>a cont?
>
>--
>Grant Edwards
>grante@visi.com
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Jeeni & ARM720T with GDB
[not found] <F170WerOc0Ne0PaLI9m00000541@hotmail.com>
@ 2000-11-21 9:36 ` Fernando Nasser
0 siblings, 0 replies; 5+ messages in thread
From: Fernando Nasser @ 2000-11-21 9:36 UTC (permalink / raw)
To: danish iftikhar; +Cc: mleibowi, gdb
danish iftikhar wrote:
>
> 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 .
>
I don't have a Jeeni target, so Grant is the person who can help you with that.
I would try "set rdiromatzero true" as it is a quick test.
Another thing you can do is to turn on Grant's RDI trace facility:
Something like
maintenance rdilogfile /dev/tty
maintenance rdilogenable on
Would print the message exchange between GDB and the target.
Do this after the load or you will have too many messages!
BTW, your program may have been linked with the wrong load address.
What is the value of the PC (P/x $pc) after the load?
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From taylor@cygnus.com Tue Nov 21 12:38:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: pathmap (again)
Date: Tue, 21 Nov 2000 12:38:00 -0000
Message-id: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00222.html
Content-length: 1370
Okay, I don't think there was complete agreement on the syntax and the
semantics, but here's a stab at what I think was agreeable to most...
Proposed Interface:
pathmap add <from> <to>
append a mapping from directory <from> to directory <to>
to the current list of mappings.
pathmap delete <optional-list>
delete the mappings indexed by <optional-list> from the
list of known mappings. All subsequent mappings move up
the list. (For example, if you delete mapping 2, then mapping
3 becomes mapping 2, mapping 4 becomes mapping 3, and so on.)
pathmap list <optional-list>
list the specified mappings. If no list is given, all
mappings are listed.
and potentially:
pathmap insert <index> <from> <to>
As for 'pathmap add', but insert the mapping immediately after
mapping <index>. All subsequent mappings move down the list.
If <index> is zero, then the mapping is inserted before the
first mapping.
Where:
<from> and <to> are directory path prefixes
<optional-list> is a list in the same format as for the
breakpoint commands
<index> is a non negative integer
And the mappings are not regular expressions -- that is left as a
potential enhancement for the future. Also, I'm unconvinced of the
need for the "pathmap insert" functionality.
Comments?
David
--
David Taylor
taylor@redhat.com, taylor@cygnus.com
From fnasser@cygnus.com Tue Nov 21 13:39:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: pathmap (again)
Date: Tue, 21 Nov 2000 13:39:00 -0000
Message-id: <3A1AEBA8.5EA780AF@cygnus.com>
References: <200011212037.PAA22391@texas.cygnus.com>
X-SW-Source: 2000-11/msg00223.html
Content-length: 2492
Well, I like it this way. It does not hurt the CLI language at all
so if you are looking for an "approval in principle" or something like that
consider it given. I will not pest you with requests to change the command
interface anymore :-)
I can only answer for the CLI aspects though. But I understood that people
liked the idea of having this around, so if I did not misunderstood I believe
everybody is sort of waiting for the patch already.
The "insert" operation is interesting. I think J.T. gave a good example of
a situation where it can be useful. But I guess it is a simple thing to add
at any time, so we may test the concept by initially not providing it and
seeing if someone asks for it (out of a personal need) or even send a patch.
IMO you should go ahead with this and submit a patch.
Fernando
David Taylor wrote:
>
> Okay, I don't think there was complete agreement on the syntax and the
> semantics, but here's a stab at what I think was agreeable to most...
>
> Proposed Interface:
>
> pathmap add <from> <to>
>
> append a mapping from directory <from> to directory <to>
> to the current list of mappings.
>
> pathmap delete <optional-list>
>
> delete the mappings indexed by <optional-list> from the
> list of known mappings. All subsequent mappings move up
> the list. (For example, if you delete mapping 2, then mapping
> 3 becomes mapping 2, mapping 4 becomes mapping 3, and so on.)
>
> pathmap list <optional-list>
>
> list the specified mappings. If no list is given, all
> mappings are listed.
>
> and potentially:
>
> pathmap insert <index> <from> <to>
>
> As for 'pathmap add', but insert the mapping immediately after
> mapping <index>. All subsequent mappings move down the list.
> If <index> is zero, then the mapping is inserted before the
> first mapping.
>
> Where:
>
> <from> and <to> are directory path prefixes
>
> <optional-list> is a list in the same format as for the
> breakpoint commands
>
> <index> is a non negative integer
>
> And the mappings are not regular expressions -- that is left as a
> potential enhancement for the future. Also, I'm unconvinced of the
> need for the "pathmap insert" functionality.
>
> Comments?
>
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
From jtc@redback.com Tue Nov 21 17:06:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region documentation
Date: Tue, 21 Nov 2000 17:06:00 -0000
Message-id: <5mem04rf23.fsf@jtc.redback.com>
References: <5mg0ku2r9l.fsf@jtc.redback.com> <200011151126.GAA03721@indy.delorie.com> <5mpujvhh52.fsf@jtc.redback.com> <200011162001.PAA04807@indy.delorie.com>
X-SW-Source: 2000-11/msg00224.html
Content-length: 883
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> However, this exercise has reminded me why I'm a programmer and not a
>> tech writer.
Eli> Actually, what you wrote was very good; the comments I had were pretty
Eli> much minor.
Thanks, but I stand by my comment --- You didn't see what went into
that draft. I spent a lot of time writing (and re-writing) it until
it reflected what I wanted to say.
>> Can you tell me where you'd like me to put this chapter? I assume
>> it's a chapter, since it doesn't seem to be a good fit into any of
>> the existing chapters --- especially if we start adding more varied
>> attributes.
Eli> It looks like between "Native Debugging" and "Support Libraries"
Eli> would be a good place.
Eh? Those chapters are in the internals document, this is intended to
be user documentation.
--jtc
--
J.T. Conklin
RedBack Networks
From d_iftikhar@hotmail.com Wed Nov 22 00:08:00 2000
From: "danish iftikhar" <d_iftikhar@hotmail.com>
To: gdb@sourceware.cygnus.com
Subject: GDB & Jeeni
Date: Wed, 22 Nov 2000 00:08:00 -0000
Message-id: <F2516byoxxSQWBLYu7A00001552@hotmail.com>
X-SW-Source: 2000-11/msg00225.html
Content-length: 4680
Hi
i am still not able to execute the program on the target boeard .
As soon as i give 'cont' , everything goes for a toss .
i am also not able to single step it ..when i give info target command , it
says "Target does not support single stepping " .
But , when i tried by using "stepi" instruction it at once moved into some
"warm-reset" assembly code ..& from there to "start" code and startted an
endless loop there .
i think that it is not able to initialise even ..
any guesses where the problem may be .
i enabled the rdilogfile , but i could'nt figure out anything from it ..
i am attaching the log file , hoping some of u may help me in this regard .
thanks
danish.
WITH rdiromatzero 1 :
ADP log file opened at Wed Nov 22 16:40:10 2000
tx: [T=0 L=25] 01 fd fc 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 00 02 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00020000
rx: [T=0 L=28] 01 fd fd 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 d3 00 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 000000d3
tx: [T=0 L=25] 01 fe fd 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 08 00 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00000800
rx: [T=0 L=28] 01 fe fe 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 60 18 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 00001860
tx: [T=0 L=28] 01 ff fe 01 03 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
60 80 00 00 04 00 00 00
R=00010003 H->T CI_HADP: ADP_Read 00008060 00000004
rx: [T=0 L=32] 01 ff ff 01 03 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00 00 70 0f e1
R=80010003 H<-T CI_HADP: ADP_Read 00000000 00000000 e10f7000
tx: [T=0 L=25] 01 00 ff 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 20 00 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00002000
rx: [T=0 L=28] 01 00 00 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 54 18 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 00001854
tx: [T=0 L=29] 01 01 00 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
8c 85 00 00 00 00 00 00 00
R=00010009 H->T CI_HADP: ADP_SetBreak 0000858c 00000000 00000000
rx: [T=0 L=36] 01 01 01 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
R=80010009 H<-T CI_HADP: ADP_SetBreak 00000000 0003ec78 001efe74 000098dc
tx: [T=0 L=24] 01 02 01 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=0001000d H->T CI_HADP: ADP_Execute 00000000
rx: [T=0 L=24] 01 02 02 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=8001000d H<-T CI_HADP: ADP_Execute 00000000
WITH rdiromatzero 0 :
ADP log file opened at Wed Nov 22 16:55:43 2000
tx: [T=0 L=25] 01 fd fc 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 00 02 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00020000
rx: [T=0 L=28] 01 fd fd 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 d3 00 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 000000d3
tx: [T=0 L=25] 01 fe fd 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 08 00 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00000800
rx: [T=0 L=28] 01 fe fe 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 60 18 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 00001860
tx: [T=0 L=28] 01 ff fe 01 03 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
60 80 00 00 04 00 00 00
R=00010003 H->T CI_HADP: ADP_Read 00008060 00000004
rx: [T=0 L=32] 01 ff ff 01 03 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00 00 70 0f e1
R=80010003 H<-T CI_HADP: ADP_Read 00000000 00000000 e10f7000
tx: [T=0 L=25] 01 00 ff 01 05 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
ff 00 20 00 00
R=00010005 H->T CI_HADP: ADP_CPUread ff 00002000
rx: [T=0 L=28] 01 00 00 01 05 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 54 18 00 00
R=80010005 H<-T CI_HADP: ADP_CPUread 00000000 00001854
tx: [T=0 L=29] 01 01 00 01 09 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
8c 85 00 00 00 00 00 00 00
R=00010009 H->T CI_HADP: ADP_SetBreak 0000858c 00000000 00000000
rx: [T=0 L=36] 01 01 01 01 09 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00 78 ec 03 00 74 fe 1e 00 dc 98 00 00
R=80010009 H<-T CI_HADP: ADP_SetBreak 00000000 0003ec78 001efe74 000098dc
tx: [T=0 L=24] 01 02 01 01 0d 00 01 00 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=0001000d H->T CI_HADP: ADP_Execute 00000000
rx: [T=0 L=24] 01 02 02 01 0d 00 01 80 00 00 00 00 ff ff ff ff ff ff ff ff
00 00 00 00
R=8001000d H<-T CI_HADP: ADP_Execute 00000000
_____________________________________________________________________________________
Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-11-22 6:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <F262O6hm8Ua8d9Ee4za00002d74@hotmail.com>
2000-11-20 8:48 ` Jeeni & ARM720T with GDB Fernando Nasser
[not found] ` <20001120110414.B23797@spanky>
2000-11-20 9:18 ` Fernando Nasser
[not found] ` <20001120162925.B11863@visi.com>
[not found] ` <20001120173821.B24131@spanky>
2000-11-20 15:43 ` Grant Edwards
[not found] <F170WerOc0Ne0PaLI9m00000541@hotmail.com>
2000-11-21 9:36 ` Fernando Nasser
[not found] <F2693AmsfGdMNFmWAFs00000388@hotmail.com>
2000-11-22 6:36 ` Grant Edwards
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox