Re: Pascal language support patch preparation

Re: Pascal language support patch preparation

[Mark Kettenis]

   Date: Thu, 02 Mar 2000 15:36:54 +0100
   From: Pierre Muller <muller@cerbere.u-strasbg.fr>

     The logs are also useless as most only are weekly imports from the
   workers CVS 
   before the CVS was made public!

Looks like we need to teach you the concept of ChangeLogs :-).  Take a
look at the files named ChangeLog* in the GDB source directory of your
checked out sources.  They list all the changes made to the sources
over the years.

Preferably you would include ChangeLog entries with you patches too.

Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: hollerer@gmx.net
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debugging via rs332c - output lost
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38951B76.E2AC3DCE@cygnus.com>
References: <Pine.SGI.3.95.1000112145321.6887B-100000@world.std.com>
X-SW-Source: 2000-q1/msg00075.html
Content-length: 690

Quality Quorum wrote:
> 
> On Wed, 12 Jan 2000 hollerer@gmx.net wrote:
> 
> > hi,
> >
> > i am remote debugging programs which makes output
> > like
> >   printf("xxx called\r\n");
> >
> > it outputs the string on it's serial interface.
> > the same interface as used for gdb.
> > debugging generally works. but the host gdb does not
> > show the sent string.
> > what must i do that the host gdb shows output of the
> > remote program?
> 
> wrap it into 'O' message.

To expand a little on this.  You will need to encode the output string
using the ``O'' packet . See "Communication protocol"
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#SEC115 (the URL
may be wrong).

	Andrew
From eliz@gnu.org Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@gnu.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002111929.OAA13997@mescaline.gnu.org>
References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <bg0v08f69.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00225.html
Content-length: 492

Andrew Cagney writes:

> > So having said all that, do you still want submit.html or equivalent
> > in the distribution?  Having it both places seems like kind of a
> > maintenance pain and seems to me that having the distribution point
> > to the web site probably works.
> 
> Yes,  I think the GDB distribution should contain the document.

Perhaps it is better to make this document part of the GDB manual.
Then we could be sure it won't be forgotten due to changing fortunes
of time...
 
From mark@codesourcery.com Sat Apr 01 00:00:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE
Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000302023420H.mitchell@codesourcery.com>
References: <bd7pe3t7t.fsf@rtl.cygnus.com> <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00493.html
Content-length: 762

>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:

    Peter> For practical debugging purposes (especially C++), the line
    Peter> number information (and thus the breakpoint) has to be put
    Peter> before the initialization code for local variables, so that
    Peter> we can debug object initialization.

But the line number itself doesn't have to indicate the `{'; it could
indicate the next line, if that's what GDB wants.  This is more
possible than it used to be since the C++ front-end now puts out whole
functions at once, rather than processing a statement at a time.

Still, it's non-trivial.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: "Daniel Berlin+mail.gdb" <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: RTTI working for G++
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003161127110.4096-100000@hpcll168.cup.hp.com>
References: <k8j3bkp2.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00726.html
Content-length: 10093

>> ... However, one of the fixes was that when print
>> object is on, and one wants to print member / methods of the derived
>> type, you can now do so. 
>
>See, i didn't consider that a bug, i considered it a lacking
>feature. It just wasn't doing the lookup it would need to do, and i've
>been too busy to fix it.

If 'print foo' says it's a pointer to something, and 'print foo->a' says
'There is no member or method named a.', it's very confusing to the
user.  When print object is on, this could happen.  I'd be more willing
to say it's a bug, since the error message contradicts with what print
says and just misleads user ('which one should I believe from this
debugger?').

The fix is in eval.c (evaluate_subexp_standard): it needs to know if
objectprint is set, and if so, return the pointer to the rtti type when
dealing with STUCTOP_PTR (if target type code is TYPE_CODE_CLASS).

>> Besides, there're some fixes to handle pointer
>> to a derived type and explicit casting of a pointer to a base to a
>> derived type. 
>
>This i ran up against. I also handled reference types (By pretending
>they were pointers).

Actually the example you gave at the end of this email looks like
something I fixed, in the casting code.  I'm not familiar with
value_rtti_type and don't quite understand what you were dealing with --
full, etc. are all reset to initial values upon entry into
value_rtti_type ().

>Did you notice that it's not really fun to use value_nid (damn
>flyspell keeps "correcting" the IND to nid, as if "nid" was really a word
>either.) in value_rtti_type? value_nid will call the RTTI routine
>during it's lazy evaluation, which gets you into a recursive nightmare
>if you aren't careful.

I wasn't adventuring into that area since I'm looking at the higher
layer of the proper handling of casting, printing, and expression
evaluation.

>I'd be glad to incorporate your fixes into my patch, and i'd
>appreciate it if you'd look at mine.
>I'll post it to gdb-patches in a few days.

Mine is enclosed in this email.

>I'm a little confused about the semantics of using_enc/full/top in value_rtti_type.
>
>It seems if i set full to 0, on multiple inheritance, it gets the name
>right, but the offset wrong, so you have the right name, and the wrong
>values.
>If i set full to 1, it gets the name wrong ("suspicious *", which
>means it couldn't look it up right), but the values right.

See if my changes to c-valprint.c and valops.c solved your problem.  I
think at least part of the problem is that the pointer value was _not_
adjusted when you change the type of the thing to a rtti type, which is
fixed in these two files.  c-valprint.c deals with printing the pointer
value itself; valops.c deals with printing a member of the pointer value.

Patch follows (the change to typeprint.c probably conflicts with your
version, and I like the output you provided).

- Jimmy Guo, guo@cup.hp.com

Thu Mar 16 15:49:56 2000	Jimmy guo	<guo@cup.hp.com>

	* c-valprint.c (c_value_print): adjust pointer value when
	objectprint is set and pointer type is changed to point to the
	rtti type.

	* eval.c (evaluate_subexp_standard): for OP_VAR_VALUE, always
	return full value object; for STRUCTOP_PTR, use pointer to
	rtti type to get member / method if objectprint is set and
	target type of pointer is class.

	* typeprint.c (whatis_exp): if objectprint is set and exp is of
	pointer / reference type to a class object, look up and print
	the pointer / reference to rtti type.

	* valops.c (value_cast): when casting a pointer / reference type
	of a class object to pointer / refer to its rtti type, adjust
	the new pointer value accordingly.


Index: c-valprint.c
/usr/local/bin/diff -c -w -L c-valprint.c c-valprint.c@@/main/cygnus/7 c-valprint.c
*** c-valprint.c
--- c-valprint.c	Thu Mar 16 10:21:16 2000
***************
*** 497,502 ****
--- 497,505 ----
                    /* create a reference type referencing the real type */
                    type = lookup_reference_type (real_type);
                  }
+ 	      /* JYG: Need to adjust pointer value. */
+               val->aligner.contents[0] -= top;
+ 
                /* Note: When we look up RTTI entries, we don't get any 
                   information on const or volatile attributes */
              }
Index: eval.c
/usr/local/bin/diff -c -w -L eval.c eval.c@@/main/cygnus/9 eval.c
*** eval.c
--- eval.c	Thu Mar 16 15:41:34 2000
***************
*** 37,42 ****
--- 37,45 ----
  /* This is defined in valops.c */
  extern int overload_resolution;
  
+ /* JYG: lookup rtti type of STRUCTOP_PTR when this is set to continue
+    on with successful lookup for member/method of the rtti type. */
+ extern int objectprint;
  
  /* Prototypes for local functions. */
  
***************
*** 428,459 ****
        (*pos) += 3;
        if (noside == EVAL_SKIP)
  	goto nosideret;
-       if (noside == EVAL_AVOID_SIDE_EFFECTS)
- 	{
- 	  struct symbol *sym = exp->elts[pc + 2].symbol;
- 	  enum lval_type lv;
- 
- 	  switch (SYMBOL_CLASS (sym))
- 	    {
- 	    case LOC_CONST:
- 	    case LOC_LABEL:
- 	    case LOC_CONST_BYTES:
- 	      lv = not_lval;
- 	      break;
  
! 	    case LOC_REGISTER:
! 	    case LOC_REGPARM:
! 	      lv = lval_register;
! 	      break;
  
- 	    default:
- 	      lv = lval_memory;
- 	      break;
- 	    }
- 
- 	  return value_zero (SYMBOL_TYPE (sym), lv);
- 	}
-       else
  	return value_of_variable (exp->elts[pc + 2].symbol,
  				  exp->elts[pc + 1].block);
  
--- 431,446 ----
        (*pos) += 3;
        if (noside == EVAL_SKIP)
  	goto nosideret;
  
!       /* JYG: We used to just return value_zero of the symbol type
! 	 if we're asked to avoid side effects.  Otherwise we return
! 	 value_of_variable (...).  However I'm not sure if
! 	 value_of_variable () has any side effect.
! 	 We need a full value object returned here for whatis_exp ()
! 	 to call evaluate_type () and then pass the full value to
! 	 value_rtti_target_type () if we are dealing with a pointer
! 	 or reference to a base class and print object is on. */
  
        return value_of_variable (exp->elts[pc + 2].symbol,
  				exp->elts[pc + 1].block);
  
***************
*** 1051,1056 ****
--- 1038,1068 ----
        arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside);
        if (noside == EVAL_SKIP)
  	goto nosideret;
+ 
+       /* JYG: if print object is on we need to replace the base type
+ 	 with rtti type in order to continue on with successful
+ 	 lookup of member / method only available in the rtti type. */
+       {
+         struct type *type = VALUE_TYPE (arg1);
+         struct type *real_type;
+         int full, top, using_enc;
+         
+         if (objectprint &&
+             (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_CLASS))
+           {
+             real_type = value_rtti_target_type (arg1, &full, &top, &using_enc);
+             if (real_type)
+               {
+                 if (TYPE_CODE (type) == TYPE_CODE_PTR)
+                   real_type = lookup_pointer_type (real_type);
+                 else
+                   real_type = lookup_reference_type (real_type);
+ 
+                 arg1 = value_cast (real_type, arg1);
+               }
+           }
+       }
+ 
        if (noside == EVAL_AVOID_SIDE_EFFECTS)
  	return value_zero (lookup_struct_elt_type (VALUE_TYPE (arg1),
  						   &exp->elts[pc + 2].string,
Index: typeprint.c
/usr/local/bin/diff -c -w -L typeprint.c typeprint.c@@/main/cygnus/6 typeprint.c
*** typeprint.c
--- typeprint.c	Thu Mar 16 09:59:00 2000
***************
*** 82,87 ****
--- 82,88 ----
    register value_ptr val;
    register struct cleanup *old_chain = NULL;
    struct type *real_type = NULL;
+   struct type *type;
    int full = 0;
    int top = -1;
    int using_enc = 0;
***************
*** 96,112 ****
    else
      val = access_value_history (0);
  
    real_type = value_rtti_type (val, &full, &top, &using_enc);
  
    printf_filtered ("type = ");
  
!   if (real_type && objectprint)
!     printf_filtered ("/* real type = %s%s */\n",
! 		     TYPE_NAME (real_type),
! 		     full ? "" : " (incomplete object)");
!   /* FIXME: maybe better to use type_print (real_type, "", gdb_stdout, -1); */
  
!   type_print (VALUE_TYPE (val), "", gdb_stdout, show);
    printf_filtered ("\n");
  
    if (exp)
--- 97,136 ----
    else
      val = access_value_history (0);
  
+   type = VALUE_TYPE (val);
+ 
+   if (objectprint)
+     {
+       if (((TYPE_CODE (type) == TYPE_CODE_PTR) ||
+            (TYPE_CODE (type) == TYPE_CODE_REF))
+           &&
+           (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_CLASS))
+         {
+           real_type = value_rtti_target_type (val, &full, &top, &using_enc);
+           if (real_type)
+             {
+               if (TYPE_CODE (type) == TYPE_CODE_PTR)
+                 real_type = lookup_pointer_type (real_type);
+               else
+                 real_type = lookup_reference_type (real_type);
+             }
+         }
+       else if (TYPE_CODE (type) == TYPE_CODE_CLASS)
          real_type = value_rtti_type (val, &full, &top, &using_enc);
+     }
  
    printf_filtered ("type = ");
  
!   if (real_type)
!     {
!       printf_filtered ("/* real type = ");
!       type_print (real_type, "", gdb_stdout, -1);
!       if (! full)
!         printf_filtered (" (incomplete object)");
!       printf_filtered (" */\n");    
!     }
  
!   type_print (type, "", gdb_stdout, show);
    printf_filtered ("\n");
  
    if (exp)
Index: valops.c
/usr/local/bin/diff -c -w -L valops.c valops.c@@/main/cygnus/15 valops.c
*** valops.c
--- valops.c	Thu Mar 16 10:01:30 2000
***************
*** 326,331 ****
--- 326,337 ----
  		      value_ptr v2 = value_ind (arg2);
  		      VALUE_ADDRESS (v2) -= VALUE_ADDRESS (v)
  			+ VALUE_OFFSET (v);
+ 
+                       /* JYG: adjust the new pointer value and
+ 			 embedded offset. */
+                       v2->aligner.contents[0] -=  VALUE_EMBEDDED_OFFSET (v);
+                       VALUE_EMBEDDED_OFFSET (v2) = 0;
+ 
  		      v2 = value_addr (v2);
  		      VALUE_TYPE (v2) = type;
  		      return v2;

Re: Pascal language support patch preparation

[Mark Kettenis]

   Date: Thu, 02 Mar 2000 15:16:19 +0100
   From: Pierre Muller <muller@cerbere.u-strasbg.fr>

   >Patches to create those new p-* files cannot be broken up of course,
   >but your patch also touches a lot of the other GDB files.  Breaking
   >those patches up in smaller though functionally related chunks makes
   >reviewing and applying the patches a lot easier.
   >
   >I'd advise you to do the following:
   >
   >1. If you need some tweaks in GDB that do not depend on the Pascal
   >   support itself, start submitting these ASAP.

     I don't think I really have such code !

Are you sure?  The patch I downloaded last fall includes changes to
breakpoint.c, findvar.c, i387-tdep.c, infcmd.c and source.c that seem
to be pretty independent of Pascal at first glance.

   >2. Then send the new p-* as one single patch.

    Alone ? tihs would just leave them  unused first !

That's not a problem.  The point is that these changes cannot break
anything, so they don't need a lot of attention.

   >3. Then send a patch that adds the code to hook in the GDB support.

    OK, here a would have the biggest part of the problems probably
   because some of the change are not trivial but I agree that I can probably
   splitt those.

That would indeed be best, since that lets the maintainer of that
particular part of GDB deal with problems one at a time, which in
general gets the changes integrated much quicker.

     For instance a big problem on which I spent a lot of time is to 
   get GDB to accept the fact the pascal is case insensitive
   this required changes in gnu-regex code !!

I'm sorry to hear that you spent a lot of time on it.  Modifying the
regex code is something that we should only do as a last resort since
it is shared with a lot of other GNU packages.  Maybe GDB should use
the POSIX functions instead of the BSD functions such that REG_ICASE
can be used when the default language is Pascal.

On the bright side: Case insensitivity would be convenient, but should
not be essential for basic Pascal support in GDB.  We should be able
to address this as a seperate issue.  I'll see what I can do.  For now
it is probably better to leave out this bit when you send your new
patches.

   >   indent --version gives "GNU indent 2.2.5"
   >   is that not the current version ??
   >
   >Yes it is, but it isn't the version that was used for reformatting the
   >GDB sources.  See:
   >
   >   http://sourceware.cygnus.com/ml/gdb/1999-q3/msg00014.html

    This not really very informative on the method that was used to do it !

Pardon me?  It clearly states that:  ``[Stan] used indent 1.9.1 (with
no arguments)''.

Mark
From taylor@cygnus.com Sat Apr 01 00:00:00 2000
From: David Taylor <taylor@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: Pierre Muller <muller@cerbere.u-strasbg.fr>
Subject: patch mailing list (was: Re: 2 pascal language patches inserted in database)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003031637.LAA19025@texas.cygnus.com>
X-SW-Source: 2000-q1/msg00526.html
Content-length: 833

    Date: Fri, 03 Mar 2000 15:44:13 +0100
    From: Pierre Muller <muller@cerbere.u-strasbg.fr>
    Subject:

      I submitted two patches for pascal extension in the database!

      I am subscribed to gdb-patches and I think that this should be enough to
    gt also 
    all mails generated by the gdb patch database, but I saw a
    subcribe link! Why is this distinct ?

I agree wholeheartedly.

I am also surprised that when the database went live that all
maintainers weren't automatically subscribed to the relevant mailing
list.

If you had not sent this message I wouldn't have known that the pascal
patches were there.  I will try to look at this today, but I doubt
I'll have time.  I'm on vacation all next week (and not net accessible).

There also doesn't appear to be a link to the patch database from the
gdb page.

Re: Pascal language support patch preparation

[Eli Zaretskii]

>  the diffs are mainly due to the reformating thus it is very difficult to
>  find out where the code really did change!!

Use "diff -cbBw", and you will see mostly real code changes.

But do NOT send diffs generated by "diff -cbBw", as they will most
probably fail to apply.  Instead, after you have seen what/where are
the real code changes, and copied them to the p-*.* files, make the
diffs with the normal "diff -c" command.
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: muller@cerbere.u-strasbg.fr
Cc: gdb@sourceware.cygnus.com
Subject: Re: Indent -gnu ?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003021321.e22DLrF00601@delius.kettenis.local>
References: <200003021257.NAA00259@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00498.html
Content-length: 1236

   Date: Thu, 02 Mar 2000 13:41:58 +0100
   From: Pierre Muller <muller@cerbere.u-strasbg.fr>

      I want to format my PATCH for pascal extension before submitting it 
   so I read that I should use GNU indent with -gnu option !

Hi Pierre, I do hope that you'll break your patch up in some smaller
chunks.  IMHO the fact that you sent it as a large chunk, was one of
the main reasons why it was ignored last fall.  

     But I tried this on c-lang.h just to see
   and the result is that the current header file does not conform to 
   indent output !

Looks like you're using a different `indent' than was used on the GDB
sources.  I think, this shows that defining the GDB coding standards
in terms of the output of `indent' is not really workable.  I've also
noticed that `indent' sometime really messes up the output, because it
gets confused by certain constructs.

     So my question is simply should I run indent on my files
   or should I send them without !

I'd say that avoiding gratuitous reformatting is more important than
running your changes through `indent'.  Thus, make sure that your
patches only contains changes for code you really changed, and that
these changes correspond to the GNU coding standards.

Mark
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: rganesan@myrealbox.com
Cc: "Insight (GDB GUI)" <insight@sourceware.cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: GDB snapshot changes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E1A781.DE684A21@cygnus.com>
References: <38D72679.BAD97DCD@cygnus.com> <14551.20952.137585.56767@anamika>
X-SW-Source: 2000-q1/msg00833.html
Content-length: 1029

Ganesan R wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > [Sorry for the cross post.  Please set followups to
> > gdb@sourceware.cygnus.com]
> 
> > Hello,
> 
> > Firstly, I'm pleased to report that nightly snapshots appear to be
> > working reliably.  See the directory:
> >       ftp://sourceware.cygnus.com/pub/gdb/snapshots/
> > For those that are curious, ``-D'' is used so that while each snapshot
> > is created during the afternoon, it contains the sources from exactly
> > ``00:00 GMT'' each morning.
> 
> Hi,
> 
> I am missing the CVS "ready" snapshots, I mean the snapshots which I can
> unpack and then do a cvs update on them to keep in sync. Any plans to
> put them back?

I've changed things so that there are be weekly CVS snapshots (more
frequent is of marginal benefit as the first thing you do is cvs update
anyway :-).

In addition, starting tomorrow the nightly snapshots will include md5
sums.

If, after a week, none of this appears to be true, please let me know.

	Andrew
From nikulin@actsw.amat.com Sat Apr 01 00:00:00 2000
From: "Serge Nikulin" <nikulin@actsw.amat.com>
To: <gdb@sourceware.cygnus.com>
Subject: How to set RS232 speed in gdb in WinNT?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <003e01bf9b69$afc0c220$35758798@mis.amat.com>
X-SW-Source: 2000-q1/msg00852.html
Content-length: 877

Hi,

I use gdb for remote debugging of m68k target, compiled with MRI
<--host=i686-pc-cygwin32 --target=m68k-motorola-ieee>
Native MRI' X-Ray debugger does not support our home-made RTOS.
GDB works but I have few questions.

1) Currently ieee-695 bfd section is not connected to gdb, so I work without
src.
    I've checked examples of coff and aout conections and it does not look
as a 1-day job for me
    (including the fact that ieee-695 support in bfd is incomplete).
    Does anyone have ieee + gdb experience?

2) In my gdb session under WinNT I use command "target remote com1"
In this case gdb connects to COM1 at 9600 baud. I'd like to change this
speed (say, to 38400) but I can't. I've changed default speed for COM1 in
WinNT's control panel but it did not help. It looks like I have to pass that
speed to cygwin.dll somehow. How can I do that?

Thanks!

Serge.