Re: tracepoints implementation: bug in byte code generating.

[Michael Snyder <msnyder@redhat.com>]

Josef Ezra wrote:
> 
> > > > > -In actions:
> > > > > -- Trace/ref different memory ranges.
> > > >
> > > > Not sure what you mean by the above.
> > >
> > > As I mentioned before, our target is working with two memory spaces:
> regular
> > > and shared. It is very common to have a pointer in regular memory that
> > > points to a structure in shared memory which one of it's field is a
> pointer
> > > to different structure in shared memory which I would like to trace.
> > > Something like:
> > > -  Special-trace (from other memory space) X bytes in offset Y from:
> > >      - Special-trace-ref (size is pointer size) in offset Z from:
> > >            - My-regular-memory-pointer
> >
> > If we add support for separate memory spaces to GDB,
> > then I would favor adding it to the traceing syntax
> > as well.  Otherwise not.  I don't want to start throwing
> > a bunch of stuff into trace that would only be supported
> > on this target or that one.  And if GDB can't support
> > multi-address-spaces, then you wouldn't have a standard
> > way to display your results.
> >
> > The whole strength of the tracing implementation,
> > in my opinion, is that it uses the same expression
> > syntax as the rest of GDB.  Therefore whatever data
> > you collect can be used by the rest of GDB without
> > modification.
> >
> 
> What is the appropriate generic interface to trace and show other memory
> spaces? I can use a good advice here.

Well, first we would need a generic interface to DEBUG 
other memory spaces.  That was my point.  Once we had that,
then we would know how to incorporate it into trace.
But gdb is the dog and trace is the tail -- we should 
not have the tail wagging the dog.

Michael
From dberlin@redhat.com Mon Oct 23 13:38:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: That dwarf2read patch i just submitted
Date: Mon, 23 Oct 2000 13:38:00 -0000
Message-id: <m3d7grpa35.fsf@dan2.cygnus.com>
References: <m3zojvmz9j.fsf@dan2.cygnus.com> <1001023165317.ZM12542@ocotillo.lan> <m3aebvqyxy.fsf@dan2.cygnus.com> <1001023173236.ZM12624@ocotillo.lan>
X-SW-Source: 2000-10/msg00155.html
Content-length: 3534

Kevin Buettner <kevinb@cygnus.com> writes:

> On Oct 23, 12:55pm, Daniel Berlin wrote:
> 
> > Kevin Buettner <kevinb@cygnus.com> writes:
> > 
> > > On Oct 23, 10:02am, Daniel Berlin wrote:
> > > 
> > > > So no one feels slighted, that last dwarf2 patch I submitted (to add
> > > > support for .debug_loc) is based on a patch I found on gdb-patches
> > > > that is a few years old, submitted originally by one of the ADA guys.
> > > > I cleaned it up so that it works with dwarf2read of today, but if you
> > > > want credit, email me, and i'll put your name in the ChangeLog
> > > > instead.
> > > 
> > > Dan,
> > > 
> > > You should definitely give credit to the original submitter of the
> > > patch (whether they step forward or not).  Also, you should make sure
> > > that we have a copyright assignment on file for whomever submitted
> > > that patch.
> > 
> > The problem is I can't seem to find it in the archives anymore using
> > the search engine, or else I would have. I really don't want to go
> > back month by month, trying to find the patch again.
> 
> It looks to me like it was
> 
>     http://sources.redhat.com/ml/gdb-patches/1999-q2/msg00054.html
> 
> The author of this patch is Brian Nettleton.
Thanks, let me hunt him down.

> 
> > The patch is actually <30 lines of code, and thus, shouldn't require
> > copyright assignment.
> 
> I'm not sure what the metric is for requiring a copyright assignment,
> but I thought it was lower than 30.  (Perhaps Andrew could let us
> know?)

I thought it was a couple hundred lines.

> 
> Anyway, you're off by an order of magnitude.  If I'm looking at the
> right patch, it's actually 322 lines long. 

That's with context and everything, what matters is the amount of code
modified.
> The number of lines
> affected by this patch is also greater than 30.  The locblock function
> and corresponding comment alone are 39 lines.
> 
> > I also modified every line of the patch, literally.
> 
> It is true that you modified many of the lines, but you didn't touch
> *all* of them.
I was almost positive I did.
I could add support for multiple block location lists, which should
mean touching every line.

> 
> E.g, with the exception of the comment (which you split to be on two
> lines),
This was probably emacs, filling it.
>  the following section from Brian's patch appears to be identical
> to what you submitted:
> 
> + {
> +   char *loc_ptr;
> +   struct dwarf_block *result;
> + 
> +   switch (attr->form)
> +     {
> +     case DW_FORM_block:
> +     case DW_FORM_block1:
> +     case DW_FORM_block2:
> +     case DW_FORM_block4:
> +       return DW_BLOCK(attr);
> +     case DW_FORM_ref_addr:
> +     case DW_FORM_ref_udata:
> +       /* return the first block in the location list for now */
> +       loc_ptr = dwarf_loc_buffer + dwarf2_get_ref_die_offset(attr);
> 
> Even if you had modified every line from Brian's patch, he should
> still be credited for the changes.
Oh, thus I know, i'm trying to avoid having to get him to sign
copyright assignment if he hasn't already.

>  It's a maintainer's job to adapt a
> patch so that it works with current sources. 

> Adapting a patch that is
> several years old may well require substantial modification, but the
> original submitter should still be given credit.  (And if he's to be
> given credit, we must then observe the FSF's mandates regarding
> copyright assignments.)
Sigh.
I'll redo the work then.
Is there any way i can give him credit, without having to get a
copyright assignment from him?
> 
> Kevin