Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@redhat.com>
To: Josef Ezra <jezra@emc.com>
Cc: gdb-patches@sources.redhat.com, "ezra,
	josef" <ezra_josef@emc.com>,
	shagam@emc.com, sgordon@emc.com
Subject: Re: tracepoints implementation: bug in byte code generating.
Date: Thu, 19 Oct 2000 10:32:00 -0000	[thread overview]
Message-ID: <39EF3020.3F6A@redhat.com> (raw)
In-Reply-To: <004e01c039d8$774c1d50$6c219fa8@lss.emc.com>

Josef Ezra wrote:
> 
> Generating code for remote traces, the case of  "pointer1->pointer2->data"
> was not covered if pointer2's declaration involved a typedef. This simple
> fix should take care of that by checking the target type whenever the code
> is TYPE_CODE_TYPEDEF.
> 
> Regards - Josef Ezra

Josef, your change is good, but let me make it better
and feed it back to you for YOUR approval.  In the process, 
I'll show you what we would like submissions to look like.

Your problem description is fine, but this is what a 
change log entry looks like:

2000-10-19  Josef Ezra <jezra@emc.com>

        * while generating data code, cases of "collect p1->p2->data"
        where not covered if p2 is a 'typedefed' type. this simple 
        fix should forward the type pointer to the real type.

And there is already a gdb function called CHECK_TYPEDEF
for doing what you want to do:

*** ax-gdb.c    2000/07/30 01:48:24     1.6
--- ax-gdb.c    2000/10/19 17:31:08
*************** gen_struct_ref (struct agent_expr *ax, s
*** 1342,1348 ****
        gen_usual_unary (ax, value);
        gen_deref (ax, value);
      }
!   type = value->type;
  
    /* This must yield a structure or a union.  */
    if (TYPE_CODE (type) != TYPE_CODE_STRUCT
--- 1342,1348 ----
        gen_usual_unary (ax, value);
        gen_deref (ax, value);
      }
!   type = CHECK_TYPEDEF (value->type);
  
    /* This must yield a structure or a union.  */
    if (TYPE_CODE (type) != TYPE_CODE_STRUCT

OK for me to accept your change as modified?
			Thanks,
			Michael Snyder
From msnyder@redhat.com Thu Oct 19 10:35:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: DJ Delorie <dj@delorie.com>
Cc: gdb-patches@sourceware.cygnus.com, jezra@emc.com
Subject: Re: tracepoints implementation: bug in byte code generating.
Date: Thu, 19 Oct 2000 10:35:00 -0000
Message-id: <39EF30ED.5E33@redhat.com>
References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com> <200010191733.NAA03317@envy.delorie.com>
X-SW-Source: 2000-10/msg00119.html
Content-length: 469

DJ Delorie wrote:
> 
> > Your problem description is fine, but this is what a
> > change log entry looks like:
> >
> > 2000-10-19  Josef Ezra <jezra@emc.com>
> >
> >         * while generating data code, cases of "collect p1->p2->data"
> >         where not covered if p2 is a 'typedefed' type. this simple
> >         fix should forward the type pointer to the real type.
> 
> Actually, it should be "* ax-gdb.c (gen_struct_ref): While
> generating..."

Oops.  Right.
From jezra@emc.com Thu Oct 19 11:02:00 2000
From: "Josef Ezra" <jezra@emc.com>
To: "Michael Snyder" <msnyder@redhat.com>
Cc: <gdb-patches@sources.redhat.com>, "ezra, josef" <ezra_josef@emc.com>, <shagam@emc.com>, <sgordon@emc.com>
Subject: Re: tracepoints implementation: bug in byte code generating.
Date: Thu, 19 Oct 2000 11:02:00 -0000
Message-id: <005b01c039f6$f46b1390$6c219fa8@lss.emc.com>
References: <00c801c02c9a$fe671c90$6c219fa8@lss.emc.com> <39D8D1CE.3059@redhat.com> <004e01c039d8$774c1d50$6c219fa8@lss.emc.com> <39EF3020.3F6A@redhat.com>
X-SW-Source: 2000-10/msg00120.html
Content-length: 1925

> Josef Ezra wrote:
> >
> > Generating code for remote traces, the case of
"pointer1->pointer2->data"
> > was not covered if pointer2's declaration involved a typedef. This
simple
> > fix should take care of that by checking the target type whenever the
code
> > is TYPE_CODE_TYPEDEF.
> >
> > Regards - Josef Ezra
>
> Josef, your change is good, but let me make it better
> and feed it back to you for YOUR approval.  In the process,
> I'll show you what we would like submissions to look like.
>
> Your problem description is fine, but this is what a
> change log entry looks like:
>
> 2000-10-19  Josef Ezra <jezra@emc.com>
>
>         * while generating data code, cases of "collect p1->p2->data"
>         where not covered if p2 is a 'typedefed' type. this simple
>         fix should forward the type pointer to the real type.
>
> And there is already a gdb function called CHECK_TYPEDEF
> for doing what you want to do:
>
> *** ax-gdb.c    2000/07/30 01:48:24     1.6
> --- ax-gdb.c    2000/10/19 17:31:08
> *************** gen_struct_ref (struct agent_expr *ax, s
> *** 1342,1348 ****
>         gen_usual_unary (ax, value);
>         gen_deref (ax, value);
>       }
> !   type = value->type;
>
>     /* This must yield a structure or a union.  */
>     if (TYPE_CODE (type) != TYPE_CODE_STRUCT
> --- 1342,1348 ----
>         gen_usual_unary (ax, value);
>         gen_deref (ax, value);
>       }
> !   type = CHECK_TYPEDEF (value->type);
>
>     /* This must yield a structure or a union.  */
>     if (TYPE_CODE (type) != TYPE_CODE_STRUCT
>
> OK for me to accept your change as modified?
> Thanks,
> Michael Snyder
>

Michael

1. Your code is better. I can't resist this modification.
2. In the future, I will try to follow change-log-entry roles, sorry for
this one.
3. I would like to add commands to the remote protocol, is there a gnu
routine to standardizes some of those changed?

Thanks again
Josef Ezra




  parent reply	other threads:[~2000-10-19 10:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-02 11:04 bug in tracepoint protocol implementation Josef Ezra
2000-10-02 11:20 ` Michael Snyder
2000-10-03 10:29   ` Josef Ezra
     [not found]   ` <004e01c039d8$774c1d50$6c219fa8@lss.emc.com>
2000-10-19 10:32     ` Michael Snyder [this message]
     [not found]       ` <005b01c039f6$f46b1390$6c219fa8@lss.emc.com>
2000-10-19 11:06         ` tracepoints implementation: bug in byte code generating Michael Snyder
     [not found]           ` <006101c039f9$df09df60$6c219fa8@lss.emc.com>
     [not found]             ` <5mvguo5spm.fsf@jtc.redback.com>
     [not found]               ` <008501c03aad$46c9d700$6c219fa8@lss.emc.com>
     [not found]                 ` <39F090F3.2DDC@redhat.com>
     [not found]                   ` <009001c03adb$b46a7b60$6c219fa8@lss.emc.com>
2000-10-20 14:54                     ` Michael Snyder
     [not found]                       ` <003d01c03b0e$42568040$961919ac@lss.emc.com>
     [not found]                         ` <39F47D62.2B5B@redhat.com>
     [not found]                           ` <004001c03d2c$14209970$6c219fa8@lss.emc.com>
2000-10-23 13:18                             ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39EF3020.3F6A@redhat.com \
    --to=msnyder@redhat.com \
    --cc=ezra_josef@emc.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jezra@emc.com \
    --cc=sgordon@emc.com \
    --cc=shagam@emc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox