[Fwd: [RFA] Dependency of gdb on tcl/tk]

[Fwd: [RFA] Dependency of gdb on tcl/tk]

[Andrew Cagney]

John,

I'm forwarding this (as you can tell :-) to the insight list.  Given 
this really affects insight I think they are the ones to comment.

For GDB, the only thing I can think of is that the dependency be 
conditional on insight sources being present.

	Andrew
From ac131313@cygnus.com Thu Jul 26 20:04:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [rfc] New file src/gdb/gdb.h
Date: Thu, 26 Jul 2001 20:04:00 -0000
Message-id: <3B60D9D8.1020902@cygnus.com>
X-SW-Source: 2001-07/msg00666.html
Content-length: 280

Hello,

This patch moves the ``libgdb'' library declarations to a separate file 
- gdb.h.  This brings the source code into line with the documentation! 
  In the process I delete a two year old FIXME :-)

I intend committing this tweek befor the 5.1 branch.

	thoughts,
		Andrew
From ac131313@cygnus.com Thu Jul 26 20:26:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [rfa] Attempt #3: Eliminate HOST_*_FORMAT from arm-*tdep.c
Date: Thu, 26 Jul 2001 20:26:00 -0000
Message-id: <3B60DF2A.5020902@cygnus.com>
X-SW-Source: 2001-07/msg00667.html
Content-length: 1089

Hello,

Attatched is another attemt at eliminating the HOST_*_FORMAT references 
in arm-tdep.c and arm-linux-tdep.c.  I'm definitly getting closer!

This time, I also ``fixed'' the functions convert_to_extended() and 
convert_from_extended() to use portable floatformat_*() functions.

With the patch applied testing on a big-endian host using the arm-sim 
target suggests things do indeed imrove.  The tests:

gdb.base/callfuncs.exp: p t_float_values
gdb.base/callfuncs.exp: p t_float_values2
gdb.base/callfwmall.exp: p t_float_values
gdb.base/callfwmall.exp: p t_float_values2

all started passing.  At the same time I didn't see any regressions.
Interestingly, testing on a little endian host showed no change in the 
test results.

There is one FIXME.  The code always uses floatformat_arm_ext.  I'm 
windering if there needs to be both floatformat_arm_ext_big and 
floatformat_arm_ext_little.  Anyone know the exact format used when 
storing BE/LE extended floats on the arm architecture?

Anyway, I'm hopeing this is sufficient improvement over the previous 
mess to go in.

	Andrew
From ezannoni@cygnus.com Thu Jul 26 20:29:00 2001
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] sh-tdep.c fix
Date: Thu, 26 Jul 2001 20:29:00 -0000
Message-id: <15200.57860.711788.863750@krustylu.cygnus.com>
X-SW-Source: 2001-07/msg00668.html
Content-length: 1832

I discovered a little foobar.  sh_gdbarch_init was using the macro
NUM_REGS, which was being defined for the given arch in the same
call. It would pick up the value of whatever the
current_gdbarch->NUM_REGS would be. current_gdbarch is NOT the arch we
are defining.

Elena

2001-07-26  Elena Zannoni  <ezannoni@redhat.com>

	* sh-tdep.c (sh_gdbarch_init): Use SH_DEFAULT_NUM_REGS instead of
	NUM_REGS.
	(SH_DEFAULT_NUM_REGS): Define.

Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.37
diff -u -p -r1.37 sh-tdep.c
--- sh-tdep.c	2001/07/15 20:10:02	1.37
+++ sh-tdep.c	2001/07/27 03:23:26
@@ -50,6 +50,8 @@ int (*print_sh_insn) (bfd_vma, disassemb
 CORE_ADDR (*skip_prologue_hard_way) (CORE_ADDR);
 void (*do_pseudo_register) (int);
 
+#define SH_DEFAULT_NUM_REGS 59
+
 /* Define other aspects of the stack frame.
    we keep a copy of the worked out return pc lying around, since it
    is a useful bit of info */
@@ -1906,12 +1908,12 @@ sh_gdbarch_init (struct gdbarch_info inf
   set_gdbarch_max_register_raw_size (gdbarch, 4);
   set_gdbarch_max_register_virtual_size (gdbarch, 4);
   set_gdbarch_ptr_bit (gdbarch, 4 * TARGET_CHAR_BIT);
-  set_gdbarch_num_regs (gdbarch, 59);
+  set_gdbarch_num_regs (gdbarch, SH_DEFAULT_NUM_REGS);
   set_gdbarch_sp_regnum (gdbarch, 15);
   set_gdbarch_fp_regnum (gdbarch, 14);
   set_gdbarch_pc_regnum (gdbarch, 16);
   set_gdbarch_register_size (gdbarch, 4);
-  set_gdbarch_register_bytes (gdbarch, NUM_REGS * 4);
+  set_gdbarch_register_bytes (gdbarch, SH_DEFAULT_NUM_REGS * 4);
   set_gdbarch_fetch_pseudo_register (gdbarch, sh_fetch_pseudo_register);
   set_gdbarch_store_pseudo_register (gdbarch, sh_store_pseudo_register);
   set_gdbarch_do_registers_info (gdbarch, sh_do_registers_info);

Re: [Fwd: [RFA] Dependency of gdb on tcl/tk]

[Keith Seitz]

On Thu, 26 Jul 2001, Andrew Cagney wrote:

> I'm forwarding this (as you can tell :-) to the insight list.  Given
> this really affects insight I think they are the ones to comment.
>
> For GDB, the only thing I can think of is that the dependency be
> conditional on insight sources being present.

Yes, I've tested this without insight (not that I couldn't tell be looking
at it, but it doesn't hurt to be a little paranoid this close to 5.1).

I was going to mutter something about doing itcl, itk, tix, libgui, etc,
but it appears that all these already work. Hmmm. Odd. I guess tcl and tk
slipped through the cracks.

If there are no objections, please check it in.
Keith

Re: [Fwd: [RFA] Dependency of gdb on tcl/tk]

[John R. Moore]

> If there are no objections, please check it in.
> Keith

Done: Checked in to sources.