Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* patch for gdbserver/low-linux.c
@ 1999-04-12  4:31 Philip Blundell
  1999-04-12  6:12 ` Philip Blundell
  0 siblings, 1 reply; 4+ messages in thread
From: Philip Blundell @ 1999-04-12  4:31 UTC (permalink / raw)
  To: gdb-patches

This patch cleans up some of the machine dependence in low-linux.c slightly 
and adds ARM support.

1999-04-12  Philip Blundell  <philb@gnu.org>

	* config/arm/tm-arm.h (TARGET_ARM): Define.
	* config/i386/tm-i386.h (TARGET_I386): Define.
	* gdbserver/low-linux.c: Test for TARGET_I386 rather than assuming 
	that anything not M68K must be I386.
	(arm_register_u_addr): New function.

diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/config/arm/tm-arm.h gdb/config/arm/tm-arm.h
--- /home/phil/gdb/clean/gdb-4.17/gdb/config/arm/tm-arm.h	Sun Apr 11 21:56:59 1999
+++ gdb/config/arm/tm-arm.h	Sun Apr 11 19:12:27 1999
@@ -22,6 +22,8 @@
 struct value;
 #endif
 
+#define TARGET_ARM 1
+
 #define TARGET_BYTE_ORDER_SELECTABLE
 
 /* IEEE format floating point */
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/config/i386/tm-i386.h gdb/config/i386/tm-i386.h
--- /home/phil/gdb/clean/gdb-4.17/gdb/config/i386/tm-i386.h	Sun Apr 11 21:57:00 1999
+++ gdb/config/i386/tm-i386.h	Sun Apr 11 19:09:14 1999
@@ -304,4 +304,6 @@
 
 #define SP_ARG0 (1 * 4)
 
+#define TARGET_I386 1
+
 #endif /* ifndef TM_I386_H */
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/low-linux.c gdb/gdbserver/low-linux.c
--- /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/low-linux.c	Sun Apr 11 21:57:15 1999
+++ gdb/gdbserver/low-linux.c	Sun Apr 11 19:14:00 1999
@@ -166,7 +172,7 @@
     - KERNEL_U_ADDR
 #endif
 
-#ifndef TARGET_M68K
+#ifdef TARGET_I386
 /* this table must line up with REGISTER_NAMES in tm-i386v.h */
 /* symbols like 'EAX' come from <sys/reg.h> */
 static int regmap[] = 
@@ -200,7 +206,9 @@
     return (blockend + 4 * regmap[regnum]);
   
 }
-#else /* TARGET_M68K */
+#endif
+
+#ifdef TARGET_M68K
 /* This table must line up with REGISTER_NAMES in tm-m68k.h */
 static int regmap[] = 
 {
@@ -232,6 +240,16 @@
 }
 #endif
 
+#ifdef TARGET_ARM
+int
+arm_register_u_addr(blockend, regnum)
+     int blockend;
+     int regnum;
+{
+  return blockend + REGISTER_BYTE(regnum);  
+}
+#endif
+
 CORE_ADDR
 register_addr (regno, blockend)
      int regno;




^ permalink raw reply	[flat|nested] 4+ messages in thread

* patch for gdbserver/low-linux.c
  1999-04-12  4:31 patch for gdbserver/low-linux.c Philip Blundell
@ 1999-04-12  6:12 ` Philip Blundell
  0 siblings, 0 replies; 4+ messages in thread
From: Philip Blundell @ 1999-04-12  6:12 UTC (permalink / raw)
  To: gdb-patches

This patch cleans up some of the machine dependence in low-linux.c slightly 
and adds ARM support.

1999-04-12  Philip Blundell  <philb@gnu.org>

	* config/arm/tm-arm.h (TARGET_ARM): Define.
	* config/i386/tm-i386.h (TARGET_I386): Define.
	* gdbserver/low-linux.c: Test for TARGET_I386 rather than assuming 
	that anything not M68K must be I386.
	(arm_register_u_addr): New function.

diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/config/arm/tm-arm.h gdb/config/arm/tm-arm.h
--- /home/phil/gdb/clean/gdb-4.17/gdb/config/arm/tm-arm.h	Sun Apr 11 21:56:59 1999
+++ gdb/config/arm/tm-arm.h	Sun Apr 11 19:12:27 1999
@@ -22,6 +22,8 @@
 struct value;
 #endif
 
+#define TARGET_ARM 1
+
 #define TARGET_BYTE_ORDER_SELECTABLE
 
 /* IEEE format floating point */
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/config/i386/tm-i386.h gdb/config/i386/tm-i386.h
--- /home/phil/gdb/clean/gdb-4.17/gdb/config/i386/tm-i386.h	Sun Apr 11 21:57:00 1999
+++ gdb/config/i386/tm-i386.h	Sun Apr 11 19:09:14 1999
@@ -304,4 +304,6 @@
 
 #define SP_ARG0 (1 * 4)
 
+#define TARGET_I386 1
+
 #endif /* ifndef TM_I386_H */
diff -u --recursive --new-file /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/low-linux.c gdb/gdbserver/low-linux.c
--- /home/phil/gdb/clean/gdb-4.17/gdb/gdbserver/low-linux.c	Sun Apr 11 21:57:15 1999
+++ gdb/gdbserver/low-linux.c	Sun Apr 11 19:14:00 1999
@@ -166,7 +172,7 @@
     - KERNEL_U_ADDR
 #endif
 
-#ifndef TARGET_M68K
+#ifdef TARGET_I386
 /* this table must line up with REGISTER_NAMES in tm-i386v.h */
 /* symbols like 'EAX' come from <sys/reg.h> */
 static int regmap[] = 
@@ -200,7 +206,9 @@
     return (blockend + 4 * regmap[regnum]);
   
 }
-#else /* TARGET_M68K */
+#endif
+
+#ifdef TARGET_M68K
 /* This table must line up with REGISTER_NAMES in tm-m68k.h */
 static int regmap[] = 
 {
@@ -232,6 +240,16 @@
 }
 #endif
 
+#ifdef TARGET_ARM
+int
+arm_register_u_addr(blockend, regnum)
+     int blockend;
+     int regnum;
+{
+  return blockend + REGISTER_BYTE(regnum);  
+}
+#endif
+
 CORE_ADDR
 register_addr (regno, blockend)
      int regno;



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: patch for gdbserver/low-linux.c
  1999-04-14 12:46 ` Stan Shebs
@ 1999-04-14 13:20   ` Stan Shebs
  0 siblings, 0 replies; 4+ messages in thread
From: Stan Shebs @ 1999-04-14 13:20 UTC (permalink / raw)
  To: philb; +Cc: gdb-patches

pb@nexus.co.uk (Philip Blundell) writes:

> This patch cleans up some of the machine dependence in low-linux.c slightly 
> and adds ARM support.

Hi, thanks for this patch!  But I'd like to solve the problem in a
slightly different way.  gdbserver is a sort of proxy for GDB, in that
uses the same process control bits (ptrace, /proc, etc) as does native
GDB, but stripped down to fit in the small dedicated program.  However,
in the long run it's a weak strategy to maintain a pseudo-clone of
native debug support; instead I think we should work up a way to allow
gdbserver and gdb to share the low-level bits and thus automatically
have gdbserver for every port.

We can take a step along this path by making a separate low-armlinux.c
for ARM Linux and so forth, and then making low-linux.c generic.  If
you do the ARM Linux bits, I'll help with making the other changes.

							Stan
 
From rearnsha@arm.com Wed Apr 14 13:21:00 1999
From: Richard Earnshaw <rearnsha@arm.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: richard.earnshaw@arm.com
Subject: Re: support for ARM GNU/Linux 
Date: Wed, 14 Apr 1999 13:21:00 -0000
Message-id: <199904141917.UAA27757@sun52.NIS.cambridge>
References: <199904141834.LAA12554@andros.cygnus.com>
X-SW-Source: 1999-04/msg00030.html
Content-length: 2049

shebs@cygnus.com said:

>    A side-note, before ARM Architecture v4 many "undefined" 
>    instruction formats aren't guaranteed to take the undefined 
>    instruction trap. Also note that, in this respect, the ARM7TDMI
>    is NOT fully ARM v4 compliant.

> I don't quite understand - I hope ARM7TDMI is guaranteed to take the
> trap, since Angel monitors are depending on that. 

I should have been more precise with my wording.  The words in the ARM ARM 
say
that ARMv4 defines several new undefined instructions (ie instructions 
that will take the undefined instruction trap).  In fact, although the 
7TDMI is nominally v4t (and hence includes all of v4) it does not in fact 
add the new undefined instructions, though it implements the rest of the 
v4 architecture.  The new undefined instructions in v4 are all 
instructions which had no defined behaviour in earlier chips (but for 
which there was no guarantee that they would raise an exception); I 
believe most of the instructions were NOPs but I could be wrong.

In practice, I think it is only safe to rely on instructions matching

  3     2 2 2 2 2
  1     8 7 6 5 4                                     5 4 3     0
  C C C C 0 1 1 x x x x x x x x x x x x x x x x x x x x 1 x x x x 

taking the undefined trap, and even then only when the condition predicate 
is true.


>    I don't know if anyone cares about RISC iX support any more (though
>    gcc still supports it).

> You'd be most likely to know if anyone would, methinks!  Since we've
> adopted a policy of marking and ultimately deleting obsolete code in
> GDB, and RISC iX is one of the candidates, any information you could
> provide would be helpful.  Do you know if anybody is using a RISC iX
> system nowadays, and if they would have any interest in a port of
> current GDB? 

Not necessarily, it was an Acorn Product not an ARM one.  I do have one at 
home, but it's slow by today's standards and makes a lot of noise, so it 
isn't switched on very often (I really only keep it in case a problem gets 
reported).




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: patch for gdbserver/low-linux.c
       [not found] <E10Wes9-00077N-00.cygnus.patches.gdb@fountain.nexus.co.uk>
@ 1999-04-14 12:46 ` Stan Shebs
  1999-04-14 13:20   ` Stan Shebs
  0 siblings, 1 reply; 4+ messages in thread
From: Stan Shebs @ 1999-04-14 12:46 UTC (permalink / raw)
  To: philb; +Cc: gdb-patches

pb@nexus.co.uk (Philip Blundell) writes:

> This patch cleans up some of the machine dependence in low-linux.c slightly 
> and adds ARM support.

Hi, thanks for this patch!  But I'd like to solve the problem in a
slightly different way.  gdbserver is a sort of proxy for GDB, in that
uses the same process control bits (ptrace, /proc, etc) as does native
GDB, but stripped down to fit in the small dedicated program.  However,
in the long run it's a weak strategy to maintain a pseudo-clone of
native debug support; instead I think we should work up a way to allow
gdbserver and gdb to share the low-level bits and thus automatically
have gdbserver for every port.

We can take a step along this path by making a separate low-armlinux.c
for ARM Linux and so forth, and then making low-linux.c generic.  If
you do the ARM Linux bits, I'll help with making the other changes.

							Stan
 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1999-04-14 13:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-04-12  4:31 patch for gdbserver/low-linux.c Philip Blundell
1999-04-12  6:12 ` Philip Blundell
     [not found] <E10Wes9-00077N-00.cygnus.patches.gdb@fountain.nexus.co.uk>
1999-04-14 12:46 ` Stan Shebs
1999-04-14 13:20   ` Stan Shebs

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox