[drow-cplus-branch] Update templates.exp

Some missing backslashes, and other miscellaneous v3 tweaks.  Two tests
still fail: DWARF-2 and decode_line_2 don't get along because we don't have
physnames available, and printing out the template class fails because its
name has changed.  I'm thinking about attack strategies for those.

Committed to branch.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-11-01  Daniel Jacobowitz  <drow <at> mvista.com>

	* gdb.c++/templates.exp: Correct some undoubled backslashes.
	Make a synthetic operator= optional.
	(print Garply<Garply<char> >::garply): Allow const THIS pointer.

Index: testsuite/gdb.c++/templates.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/templates.exp,v
retrieving revision 1.12.18.1
diff -u -p -r1.12.18.1 templates.exp
--- testsuite/gdb.c++/templates.exp	30 Oct 2002 23:17:30 -0000	1.12.18.1
+++ testsuite/gdb.c++/templates.exp	31 Oct 2002 23:04:35 -0000
 <at>  <at>  -53,12 +53,12  <at>  <at>  proc test_ptype_of_templates {} {

     send_gdb "ptype T5<int>\n"
     gdb_expect {
-	-re "type = class T5<int> \{${ws}public:${ws}static int X;${ws}int x;${ws}int val;${ws}T5<int> &
operator=\\(T5<int> const ?&\\);${ws}T5\\(int\\);${ws}T5\\((T5<int> const|const T5<int>)

[drow-cplus-branch] v3 destructors

I've now added code to the stabs reader to report destructor field names
properly.  This changes get_destructor_fn_field_name to use that, but not to
rely on it.

I need to double-check with the HP reader, but I can probably rely on this
now, and kill all physname checks for this purpose.  One down, N to go, next
on the hitlist is decode_line_2 once I figure out an approach.  Then calling
functions.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [drow-cplus-branch] v3 destructors

On Fri, Nov 01, 2002 at 11:37:29AM -0500, Daniel Jacobowitz wrote:
> I've now added code to the stabs reader to report destructor field names
> properly.  This changes get_destructor_fn_field_name to use that, but not to
> rely on it.
> 
> I need to double-check with the HP reader, but I can probably rely on this
> now, and kill all physname checks for this purpose.  One down, N to go, next
> on the hitlist is decode_line_2 once I figure out an approach.  Then calling
> functions.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Oops, with patch.

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-11-01  Daniel Jacobowitz  <drow <at> mvista.com>

	* gdbtypes.c (get_destructor_fn_field): Return obvious destructors
	based on method name.

Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.59.2.1

[drow-cplus-branch] More type printer updates

This patch:
  - removes a completely redundant function
  - Honors artificial arguments; meant to do this ages ago and got
sidetracked.
  - Correctly considers T5 to be a constructor name for T5<int>.

Committed on the branch.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-11-01  Daniel Jacobowitz  <drow <at> mvista.com>

	* c-typeprint.c (c_type_print_args): Remove.
	(cp_type_print_method_args): Remove unused PREFIX argument.
	Simplify logic.  Skip FIELD_ARTIFICIAL arguments.
	(c_type_print_varspec_suffix): Call cp_type_print_method_args.
	(c_type_print_base): Handle template classes when looking for
	constructor field names.  Update call to cp_type_print_method_args.

Index: c-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-typeprint.c,v
retrieving revision 1.22.10.4
diff -u -p -r1.22.10.4 c-typeprint.c
--- c-typeprint.c	30 Oct 2002 23:11:47 -0000	1.22.10.4
+++ c-typeprint.c	31 Oct 2002 23:04:34 -0000
 <at>  <at>  -41,12 +41,10  <at>  <at> 
 /* Flag indicating target was compiled by HP compiler */

[patch] Deprecate generic_get_saved_register()

Hello,

The function generic_get_saved_register() was, some time ago, 
superseeded by the generic_unwind_get_saved_register().  This patch 
follows the change through by deprecating the old function.

Since GET_SAVED_REGISTER() now defaults to 
generic_unwind_get_saved_register() upgrading an architecture should 
simple - don't set the GET_SAVED_REGISTER() method.

I should also note that, not to far into the future, 
GET_SAVED_REGISTER() is going to also be deprecated.  In its place will 
be something that directly sets frame->unwind(), just need to figure out 
what that `something' is 

committed,
Andrew

2002-11-01  Andrew Cagney  <cagney <at> redhat.com>

	* frame.h (deprecated_generic_get_saved_register): Rename
	generic_get_saved_register.
	* blockframe.c (deprecated_generic_get_saved_register): Update.
	* xstormy16-tdep.c (xstormy16_get_saved_register): Update.
	(xstormy16_frame_saved_register): Update.
	* sh-tdep.c (sh_gdbarch_init): Update.
	* m68hc11-tdep.c (m68hc11_gdbarch_init): Update.
	* ia64-tdep.c (ia64_get_saved_register): Update.
	* cris-tdep.c (cris_gdbarch_init): Update.

Re: [RFC/RFA] Adding new files for Interix (take 3)

> > 2002-10-15  Joel Brobecker  <brobecker <at> gnat.com>
> > 
> >         New interix-specific files:
> >         * config/i386/nm-interix.h: New file.
> >         * config/i386/interix.mh: New file.
> >         * config/i386/interix.mt: New file.
> >         * i386-interix-nat.c: New file.
> >         * i386-interix-tdep.c: New file.
> 
> Sorry, yes, this looks much better.  So go ahead and check this in.

Thank you. Checked in.

--

-- 
Joel

[patch/rfc] Add frame_register(); GET_SAVED_REGISTER() is a predicate

Hello,

The attached patch adds a new function:

+/* Return the value of the register in this FRAME.  Convenience
+   function that is equivalent to frame_register_unwind
+   (get_next_frame (FRAME), ...).  If VALUEP is NULL, don't
+   fetch/compute the value.  */
+
+extern void frame_register (struct frame_info *frame, int regnum,
+                           int *optimizedp, enum lval_type *lvalp,
+                           CORE_ADDR *addrp, int *realnump,
+                           void *valuep);
+

This function is very like the existing frame_register_unwind() only it 
returns the value of REGNUM that belongs to FRAME and not the value that 
belongs to FRAME's caller.  Further, consistent with 
frame_register_unwind (and unlike get_saved_register()), it returns the 
registers actual location (register number) in REALNUM while 
GET_SAVED_REGISTER() was returning the register's offset (in the 
registers[] array).

The patch then modifies frame.c and valops.c to use the new function.

The reason for changing the existing GET_SAVED_REGISTER() to a predicate 
method is a bit nasty.  When a target architecture provides a 
GET_SAVED_REGISTER() method, the frame_register() function has no direct 
way of obtaining the register's REALNUM and hence is forced to compute 
that value using a simple lookup.   If an architecture does not provide 

[wanted] Test of GDB modifying a value in a register

Hello,

In doing a further cleanup of the frame code, I discovered that the 
current testsuite isn't testing the codepaths that write a value in a 
register.

That is, things like:

(gdb) set $pc = 10
register int i;
(gdb) set i = 10;

Anyone interested in comming up with, or have a test case?

Andrew

[RFA] Top level configury additions for RDA (3rd try)

My previous attempts at modifying the top level configury for RDA
consisted of adding RDA as a host module.  Daniel Jacobowitz pointed
out (privately) that it would make a lot more sense for RDA to be a
target program.  E.g, if you're building a Solaris hosted tool chain
for a i386-linux target, you really want to build RDA for the Linux
target instead of the Solaris host.  I agree with Daniel, so here's my
third (and hopefully final) try at a patch to adjust the top level
configury for RDA.

I should note that one of the problems I had when I tested this patch
was that the build would fail due to an automake problem in the rda
directory.  It turns out that this problem is fixed by regenerating
rda's Makefiles with a newer version of automake (1.6.3).  If this
patch is approved, I'll commit an updated configury for rda.

Okay to commit?

	* Makefile.def (host_modules): Add rda.
	* Makefile.in: Regenerate.
	* configure.in (target_tool): Add target-rda to list.

Index: Makefile.def
===================================================================
RCS file: /cvs/src/src/Makefile.def,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile.def
--- Makefile.def	2 Oct 2002 06:29:04 -0000	1.3
+++ Makefile.def	2 Nov 2002 00:13:43 -0000
 <at>  <at>  -77,3 +77,4  <at>  <at>  target_modules = { module= libjava; };
 target_modules = { module= zlib; };

Re: [RFA] Top level configury additions for RDA (3rd try)

> Okay to commit?
> 
> 	* Makefile.def (host_modules): Add rda.
> 	* Makefile.in: Regenerate.
> 	* configure.in (target_tool): Add target-rda to list.

Ok.