Re: [RFA] C++ method calls

Re: [RFA] C++ method calls

[Daniel Berlin+list.gdb-patches]

Nick Duffek <nsd@redhat.com> writes:

> 
> the following GDB commands should fail but don't:
> 
>   call c.ptr (&c);
>   call c.ref (c);
> 
> After fixing that with part of the appended patch, the following GDB
> commands shouldn't fail but do:
> 
>   call c.ptr (&b);
>   call c.ref (b);
> 
> The patch fixes the above problems, adds gdb.c++/classes.exp tests to
> check for them, and fixes a minor indentation problem.  It also seems to
> fix two gdb.c++/namespace.exp failures.  There are no regressions on
> sparc-sun-solaris2.
> 
> The enum test patch I posted earlier today needs to be applied first.
> 
> Okay to apply?
> 
> Nick Duffek
> nsd@redhat.com
> 
> 2000-07-08  Nick Duffek  <nsd@redhat.com>
> 
> 	* gdbtypes.c (is_ancestor): Infer type equivalence from name
> 	equivalence.
> 	(rank_one_type): Use strcmp instead of == to compare type names.
> 	Don't swap parm with arg when checking TYPE_CODE_REF types.

I probably missed this one because in DWARF2, which is what i'm almost always using, unless we hit hash table collisions, which we almost never do (you'd need a *lot* of type names), == should be sufficient to compare type names when dealing with C++.
You do realize, of course, that the fact that it isn't  means you are duplicating info when reading in STABS/DBX/whatever debug format you are using,  that you shouldn't be.

Feel free to apply them.
--Dan

Re: [RFA] C++ method calls

[Nick Duffek]

On 8-Jul-2000, Daniel Berlin+list . gdb-patches wrote:

>I probably missed this one because in DWARF2, which is what i'm almost
>always using, unless we hit hash table collisions, which we almost never
>do (you'd need a *lot* of type names), == should be sufficient to compare
>type names when dealing with C++.

The case I noticed was when both names were NULL, as happens when checking
TYPE_CODE_PTR args.

>You do realize, of course, that the fact that it isn't means you are
>duplicating info when reading in STABS/DBX/whatever debug format you are
>using, that you shouldn't be.

In the absence of a comment that type names are guaranteed to be ==, I
figured it'd be safest to do a strcmp() rather than just a NULL check.

>Feel free to apply them.

Done,

Nick
From nsd@redhat.com Sat Jul 08 22:21:00 2000
From: Nick Duffek <nsd@redhat.com>
To: dberlin@redhat.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Fix C++ enum tests
Date: Sat, 08 Jul 2000 22:21:00 -0000
Message-id: <200007090526.e695Qbg01049@rtl.cygnus.com>
References: <867lawausv.fsf@dan2.cygnus.com>
X-SW-Source: 2000-07/msg00091.html
Content-length: 444

On 8-Jul-2000, Daniel Berlin+list . gdb-patches wrote:

>Fine by me, dunno if it falls under my maintainership though, or Stans.

Since you answered first, I'll assume you. :-)

>Have you tested them with different debug info types?

Not the enum test change, because it's so obviously broken (the misc.cc
line number is just wrong).  I did ad-hoc testing of my "C++ method calls"
patch with DWARF-2, though.

I've committed this change.

Nick
From eliz@delorie.com Sat Jul 08 22:47:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: cgf@cygnus.com
Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] doc/Makefile.in patch stolen from Makefile.am
Date: Sat, 08 Jul 2000 22:47:00 -0000
Message-id: <200007090547.BAA25681@indy.delorie.com>
References: <20000708013554.A13848@cygnus.com>
X-SW-Source: 2000-07/msg00092.html
Content-length: 373

> Date: Sat, 8 Jul 2000 01:35:54 -0400
> From: Chris Faylor <cgf@cygnus.com>
> 
> >Could I suggest stealing the install-info-am: target from
> >src/bfd/doc/Makefile.in?  (calling it install-info: of course :-).
> 
> Here it is.  It was a lot easier than I thought it would be.
> I should have just done this to begin with.

I've just commited this (to the trunk).

Thanks!
From fnasser@cygnus.com Sun Jul 09 09:58:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: "Daniel Berlin+list.gdb-patches" <dberlin@redhat.com>
Cc: Nick Duffek <nsd@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Fix C++ enum tests
Date: Sun, 09 Jul 2000 09:58:00 -0000
Message-id: <3968AF20.7D05BF68@cygnus.com>
References: <200007090121.e691LLV00837@rtl.cygnus.com> <867lawausv.fsf@dan2.cygnus.com>
X-SW-Source: 2000-07/msg00093.html
Content-length: 398

"Daniel Berlin+list.gdb-patches" wrote:
> 
> Fine by me, dunno if it falls under my maintainership though, or Stans.

It would be Stan and I.  But the patch is obviously necessary.


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ezannoni@cygnus.com Sun Jul 09 12:12:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: readilne 4.1. is in
Date: Sun, 09 Jul 2000 12:12:00 -0000
Message-id: <14696.52863.864411.260537@kwikemart.cygnus.com>
X-SW-Source: 2000-07/msg00094.html
Content-length: 742

Let me know if there are any problems building gdb.

I took the item out of the TODO file as well.

Elena


Index: TODO
===================================================================
RCS file: /cvs/src/src/gdb/TODO,v
retrieving revision 1.37
diff -c -u -p -r1.37 TODO
cvs server: conflicting specifications of output style
--- TODO        2000/06/23 08:12:27     1.37
+++ TODO        2000/07/09 17:22:32
@@ -239,14 +239,6 @@ suffer bit rot.
 
 --
 
-Updated readline
-
-Readline 4.? is out.  A merge wouldn't hurt.  Patches are in:
-
- http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00436.html
-
---
-
 Deprecate "fg".  Apparently ``fg'' is actually continue.
 
 http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00417.html
From ac131313@cygnus.com Sun Jul 09 19:59:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: msnyder@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFC]: Pseudo-registers for GDB
Date: Sun, 09 Jul 2000 19:59:00 -0000
Message-id: <39693C0D.223C4C8A@cygnus.com>
References: <396632CB.55A1@cygnus.com>
X-SW-Source: 2000-07/msg00095.html
Content-length: 3527

[I suspect that I hit the wrong button half way though composing this]

Michael Snyder wrote:

> As a first step, I propose to move the register cache from
> its present ill-concieved location in findvar.c into its own
> module (tentatively named regcache.c), and to make it a true
> data object (with access functions to replace the direct
> access that some modules now make).  After that, changes to
> the data structure should have minimal impact on the rest of
> GDB.
> 
> Comments?

Yes please!

Well the first step has to be a good thing (tm).  Right now
we've no idea how various targets are using (and abusing)
register_bytes[] so placing it under some sort of control means, as you
point out, it can be re-implemented cleanly.

Interestingly,  this is the same first step that would need to be taken
if there is to be a per-thread register cache.  So definitly a
good move!

> 1) real vs. virtual frame pointer.
> Many architectures have a dedicated frame pointer register,
> but in some circumstances (eg. "frameless" leaf functions)
> there is a virtual frame pointer that is not kept in a
> register at all.  In that case the value of the "frame location"
> is different from the value of the '$fp' register.
> 
> At present, GDB will report one value if you say
> "info register $fp", and a different value if you say
> "print $fp".
> 
> With pseudo-registers, we could define a virtual FP register
> in addition to the hardware FP register.  The virtual one
> would be computed rather than fetched from the target machine.
> The confusion between the FP register and the virtual frame
> pointer would be eliminated.

In the case of the virtual-fp, since it really has nothing to do with
the target, would it be better to keep it separate from *-tdep.c and
hence regcache.[ch]?

I suspect, looking at this pragmatically, that it is far more important
to get the regcache.[hc] up and running than trying to also resolve
this.

> 2) register pairs.
> Sometimes registers can be addressed either separately or
> joined / concatenated together.  For instance, MIPS has some
> number of single-precision floating point registers, which can
> be paired into half that number of double precision regs.
> 
> We could treat the single-precision regs as real hardware
> regs, and fetch them from the target as usual.  The 
> combined (double precision) regs would be pseudo-regs; 
> addressable by name, but not needing to be fetched once
> the single-precision ones are fetched or stored.  They
> would share the same storage in the register cache, even
> as they share the same storage on the target machine.
> 
> 3) vector registers.
> Another example of shared storage.  Some architectures can
> have vector co-processors, where a largeish number of 
> register 'elements' are joined into one array of registers.
> We could store the elements in the cache as discretely 
> addressable registers, and also define a single vector
> register to address them all at once.  With such large
> registers, the disadvantage of fetching the values twice
> are easy to see.

A slightly more technical question.  When GDB displays register
information for the non-inner most frame, it uses a union of information
obtained from both a ``struct frame'' and the register buffer.  

I guess the strategy here is to first get regcache.[ch] working and
supporting virtual registers and then, later update the frame code so
that it can handle things the same way.  Assuming that is the stragegy
then it is definitly a good move.

	Andrew
From ac131313@cygnus.com Sun Jul 09 20:27:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: find_saved_register(frame) -> next/prev frame?
Date: Sun, 09 Jul 2000 20:27:00 -0000
Message-id: <39694282.8066451A@cygnus.com>
X-SW-Source: 2000-07/msg00096.html
Content-length: 1595

Hello,

The function find_saved_register() uses:

  /* Note that this next routine assumes that registers used in
     frame x will be saved only in the frame that x calls and
     frames interior to it.  This is not true on the sparc, but the
     above macro takes care of it, so we should be all right. */
  while (1)
    {
      QUIT;
      frame1 = get_prev_frame (frame1);
      if (frame1 == 0 || frame1 == frame)
        break;
      FRAME_INIT_SAVED_REGS (frame1);
      if (frame1->saved_regs[regnum])
        addr = frame1->saved_regs[regnum];
    }

find the frame that contains a registers value.  I'm right now very
confused as I think it is looking in the wrong direction.

Consider the stack:

	main()
	-> outer ()
	   saves r1, r2
	-> middle ()
	   saves r2, r3
	-> inner()
	   saves r1, r3

lets assume that we've just selected the frame for middle().  I think we
should find register values at:

	r1: in inner()' stack frame
	r2: in the register cache
	r3: in inner()'s stack frame

Looking at the above implementation.  My understanding of
``get_prev_frame()'' is that it goes to the next _outer_ frame.  It
should be calling get_next_frame() going to the next inner frame.  It
also appears to contract the comment attatched to the code.

Can I rename get_next_frame() to get_inner_frame() and get_prev_frame()
to get_outer_frame() :-)

	Andrew

PS: I should note that this code has remained largely unchanged since
'91 (which is as far back as CVS history goes!) so either something
really wierd is going on or I'm missing something obvious - I guess we
suspect the latter.
From thomasb@novagate.net Sun Jul 09 20:28:00 2000
From: Tom <thomasb@novagate.net>
To: gdb-patches@sourceware.cygnus.com
Subject: Ad: Are You Financially Healthy?
Date: Sun, 09 Jul 2000 20:28:00 -0000
Message-id: <200007100328.XAA15753@mailgate.novagate.net>
X-SW-Source: 2000-07/msg00097.html
Content-length: 771

Thanks for posting to my FFA links page
hosted by FFA-USA.net
***************************************

Unleash the power of your computer and learn who to use it to become 
Financially FREE in 60 Minutes a Day! 

Sincerely:
Tom Bell
Holland, MI
LFI: 20262162
http://hotyellow98.com/force2000/





**************************************************************************

Here's another program that has worked very well for me!
 It won't cost you a thing to take the tour. But it could cost  you 
 an early retirerment or a new car or any number of the things  you have wanted 
but could'nt afford. If you don't at least  check it  out you will never know.

http://hotyellow98.com/force2000/
**************************************************************************