Tracepoints functionality for local targets

Tracepoints functionality for local targets

[Lokesh Gupta]

Hello,

Is there some work planned for the working of the tracepoints for
local targets? While going through the source code, I realized that
currently this facility is only for remote targets.
In case nothing is planned, can I have some guidance on how to achieve
this. I think that it could be a good enhancement to debug
multi-threaded programs on the local host.

Regards
Lokesh Gupta

Re: Tracepoints functionality for local targets

[Daniel Jacobowitz]

On Tue, Feb 26, 2008 at 09:27:47AM +0100, Lokesh Gupta wrote:
> Hello,
> 
> Is there some work planned for the working of the tracepoints for
> local targets?

Not yet, but Doug was talking about it on this list a few days ago.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Tracepoints functionality for local targets

[Doug Evans]

On Tue, Feb 26, 2008 at 5:10 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, Feb 26, 2008 at 09:27:47AM +0100, Lokesh Gupta wrote:
>  > Hello,
>  >
>  > Is there some work planned for the working of the tracepoints for
>  > local targets?
>
>  Not yet, but Doug was talking about it on this list a few days ago.

http://sourceware.org/ml/gdb/2008-02/msg00156.html

The thread starts out talking about gdbserver, but both it and native
are (briefly) discussed.  At this point I'm just researching projects,
I'm not actively working on this one.

Re: Tracepoints functionality for local targets

[Nicholas Mc Guire]

> >  >
> >  > Is there some work planned for the working of the tracepoints for
> >  > local targets?
> >
> >  Not yet, but Doug was talking about it on this list a few days ago.
>
> http://sourceware.org/ml/gdb/2008-02/msg00156.html
>
> The thread starts out talking about gdbserver, but both it and native
> are (briefly) discussed.  At this point I'm just researching projects,
> I'm not actively working on this one.
>

well we actually use gdb tracepoints with local targets via gdbserver and
as that works just fine I don't see much point in having two
implementations - the overhead of having a local gdbserver running is not
too high. Note though that with Linux at least there are some subtle
problems related to the way ptraced processes are woken up resulting in
relatively large delays in the child process being traced (see infos and
traces at http://dslab.lzu.edu.cn/~hofrat/tp.html)

patches for tracepoints can also be found at
ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints/

hofrat

Re: Tracepoints functionality for local targets

[Doug Evans]

On Sat, Mar 1, 2008 at 12:33 PM, Nicholas Mc Guire <hofrat@hofr.at> wrote:
>  patches for tracepoints can also be found at
>  ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints/

Thanks.  I'm assuming copyright for the patches hasn't been assigned
to the FSF yet.
[If that's incorrect, excellent.]  Can they be?

No point in reinventing wheels if one doesn't have to.

Re: Tracepoints functionality for local targets

[Nicholas Mc Guire]

> >  patches for tracepoints can also be found at
> >  ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints/
>
> Thanks.  I'm assuming copyright for the patches hasn't been assigned
> to the FSF yet.
> [If that's incorrect, excellent.]  Can they be?
>

It is GPL V2 and not assigned to the FSF - it was funded by Siemens AG
(Cooperate Technology) and Im talking to them - but it took 1 year to
get them to release it under the GPL and get permission to release it to
the public so don't expect this to happen any time soon - anyway it is a
supprise to me that it is insufficient to release code under the GPL V2
and frankly if the FSF requires copyright assignment then this is bad news
for free software developers - what reason could I give any other company
to require the same ? On the other hand if the FSF has legitimate reasons
not to accept GPL code as it could lead to restrictions then this would
be the case for any commercial entity as well and be really bad news for
GPL all together. So I still hope that the GPL V2 code would be accepted
by the GDB people.

> No point in reinventing wheels if one doesn't have to.
>

thx!
hofrat

Re: Tracepoints functionality for local targets

[Robert Dewar]

Nicholas Mc Guire wrote:

> It is GPL V2 and not assigned to the FSF - it was funded by Siemens AG
> (Cooperate Technology) and Im talking to them - but it took 1 year to
> get them to release it under the GPL and get permission to release it to
> the public so don't expect this to happen any time soon - anyway it is a
> supprise to me that it is insufficient to release code under the GPL V2
> and frankly if the FSF requires copyright assignment then this is bad news
> for free software developers 

The FSF requires that people assign the copyright, this keeps the
copyright situation clear on the whole project. You have to be very
careful in copying code, just because someone somewhere says some
code is under the GPL does not make it so, you have to be 100% sure
that the person owning the copyright has issued the license, and the
way that FSF project does this is to insist on formal copyright
assignment. No one is compelled to do such an assignment of course,
but for the code to be part of the FSF GNU project, the FSF does
require this assignment.

> - what reason could I give any other company
> to require the same ?

The same reason that has convinced hundreds of individuals and
major corporations to assign code. If you assign the code to the
FSF, then it gets mainlined into the FSF development sources,
which means your patches are continuously tested, and you don't
have to deal with reinserting them in every new release.

If Siemens is interested in having this code be mainlined
into the GDB sources, they have to agree to the assignment.
If they are not interested in this, then they don't need
to agree, and unfortunately it won't happen.

> On the other hand if the FSF has legitimate reasons
> not to accept GPL code as it could lead to restrictions then this would
> be the case for any commercial entity as well and be really bad news for
> GPL all together. 

It's is not a matter of restrictions, just a matter of being
careful about copyright and ownership. The GPL is not some magic
that removes this requirement for diligence.

> So I still hope that the GPL V2 code would be accepted
> by the GDB people.

There does need to be an assignment for it to be incorporated

Re: Tracepoints functionality for local targets

[Nicholas Mc Guire]

> Nicholas Mc Guire wrote:
>
> > It is GPL V2 and not assigned to the FSF - it was funded by Siemens AG
> > (Cooperate Technology) and Im talking to them - but it took 1 year to
> > get them to release it under the GPL and get permission to release it to
> > the public so don't expect this to happen any time soon - anyway it is a
> > supprise to me that it is insufficient to release code under the GPL V2
> > and frankly if the FSF requires copyright assignment then this is bad news
> > for free software developers
>
> The FSF requires that people assign the copyright, this keeps the
> copyright situation clear on the whole project. You have to be very
> careful in copying code, just because someone somewhere says some
> code is under the GPL does not make it so, you have to be 100% sure
> that the person owning the copyright has issued the license, and the
> way that FSF project does this is to insist on formal copyright
> assignment. No one is compelled to do such an assignment of course,
> but for the code to be part of the FSF GNU project, the FSF does
> require this assignment.

of course you need to be sure about the GPL V2 license being issued by the
copyrigth holder and not mearly me claiming this - but there is a
fundamental step from "requirement of verified free-software compliant
copyright" and requirement of assigning copyright to the FSF - the
argument of clean and assured copyright definitly does not legitimate this
policy - or atleast at this point I don't see why - could you explain
this in more detail ?

>
> > - what reason could I give any other company
> > to require the same ?
>
> The same reason that has convinced hundreds of individuals and
> major corporations to assign code. If you assign the code to the
> FSF, then it gets mainlined into the FSF development sources,
> which means your patches are continuously tested, and you don't
> have to deal with reinserting them in every new release.

I don't see the need for copyright assigment to the FSF for that - other
comparably large projects (i.e. Linux kernel) handle this properly
withouth any such policy. Assurance of legitimacy is an issue in any case
and not reduced by the filing of assigment forms in any way.

>
> If Siemens is interested in having this code be mainlined
> into the GDB sources, they have to agree to the assignment.
> If they are not interested in this, then they don't need
> to agree, and unfortunately it won't happen.

That is one oversimplified way of seeing it - but I strongly feel this is
clearly contradicting the ideas and intentions of free-software all
together which is bad for the community, notably bad for motivating
companies to support free-software and not mearly open-source.

>
> > On the other hand if the FSF has legitimate reasons
> > not to accept GPL code as it could lead to restrictions then this would
> > be the case for any commercial entity as well and be really bad news for
> > GPL all together.
>
> It's is not a matter of restrictions, just a matter of being
> careful about copyright and ownership. The GPL is not some magic
> that removes this requirement for diligence.

well - assurance of copyright and carfullness don't mandate assigment of
copyright - that is clearly coupling two unrelated problems. If I sign
the paperwork - what assurance do you have then ? If I fraudulently assign
copyrigth - what good is that ? so pleas where is the difference in
assurance of a clear and legal release under a free-software license and
the assigment requirement ? what limitations does the FSF see if I would
get Siemens to sign a statement they released the tracepoint code under
GPL V2 ?

>
> > So I still hope that the GPL V2 code would be accepted
> > by the GDB people.
>
> There does need to be an assignment for it to be incorporated
>

well - we will try to maintain it out of tree if we can get the resources
but it will not be easy.

thx!
hofrat

Re: Tracepoints functionality for local targets

[Robert Dewar]

Nicholas Mc Guire wrote:

> of course you need to be sure about the GPL V2 license being issued by the
> copyrigth holder and not mearly me claiming this - but there is a
> fundamental step from "requirement of verified free-software compliant
> copyright" and requirement of assigning copyright to the FSF - the
> argument of clean and assured copyright definitly does not legitimate this
> policy - or atleast at this point I don't see why - could you explain
> this in more detail ?

This is established policy which is not about to be changed,
and it is not appropriate to discuss it on this list. I will
send a private message.

Re: Tracepoints functionality for local targets

[Richard Stallman]

The reason we ask for a copyright assignment or disclaimer before we
install code is because our lawyers tell us this is important for
enforcing the GPL in court.  Many packages "get along without this"
because they do not trouble themselves about how they will do that.

The next version of GDB should be released under GPLv3 or later.
Therefore, a module released under GPLv2 _only_ can't be part of
modified GDB versions, unless you limit yourself to using the old
versions of GDB.  And we certainly could not include it in GDB.
"GPLv2 only" is a free license but it is not a good way to do the job,
which is why we never do that.

Re: Tracepoints functionality for local targets

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: dewar@adacore.com, dje@google.com, lokesh.gupta@gmail.com, 	gdb@sourceware.org
> Date: Mon, 03 Mar 2008 05:09:02 -0500
> 
> The next version of GDB should be released under GPLv3 or later.

Actually, even the last version of GDB, 6.7.1, was already released
under GPLv3.

Re: Tracepoints functionality for local targets

[Richard Stallman]

    Actually, even the last version of GDB, 6.7.1, was already released
    under GPLv3.

(I had no way to check.)

In that case, what I said applies to the current version of GDB as well.

Re: Tracepoints functionality for local targets

[Michael Snyder]

On Tue, 2008-02-26 at 09:27 +0100, Lokesh Gupta wrote:
> Hello,
> 
> Is there some work planned for the working of the tracepoints for
> local targets? While going through the source code, I realized that
> currently this facility is only for remote targets.
> In case nothing is planned, can I have some guidance on how to achieve
> this. I think that it could be a good enhancement to debug
> multi-threaded programs on the local host.

You could define it as two challenges to be addressed:
1) How to instrument the code and collect the data on a 
native system, and
2) the fact that the gdb side is only written to handle
the remote target.

I would certainly love to see a native implementation
happen, and it would be fair to say that #2 is my fault, 
so if somebody were to seriously undertake solving #1, 
I would undertake to at least help work on #2...

Michael

Re: Tracepoints functionality for local targets

[Lokesh Gupta]

Hello,

Can't we take the following approach to this issue:

- Treat tracepoints as 'silent' breakpoints such that when the user
sets tracepoints actually a breakpoint is inserted with a special
property called as 'trace-silent'
- During execution, when this breakpoint is hit, the usual GDB flow of
handling the breakpoint comes into picture, GDB gets control, it
collects all required data from the current frame ($regs,$args,$locals
as requested by user for this tracepoint), and then silently continues
the execution because it can identify it as a special breakpoint with
the property of 'trace-silent'
- The data which is collected by an enabled tracepoint is stored as a
'snapshot' which is a node in a linked list of all snapshots collected
during program execution. This linked list could be used for the
implementation of the tfind like functions to provide necessary
information to the user.

Regards
Lokesh Gupta

On Tue, Feb 26, 2008 at 7:38 PM, Michael Snyder <msnyder@specifix.com> wrote:
>
> On Tue, 2008-02-26 at 09:27 +0100, Lokesh Gupta wrote:
>  > Hello,
>  >
>  > Is there some work planned for the working of the tracepoints for
>  > local targets? While going through the source code, I realized that
>  > currently this facility is only for remote targets.
>  > In case nothing is planned, can I have some guidance on how to achieve
>  > this. I think that it could be a good enhancement to debug
>  > multi-threaded programs on the local host.
>
>  You could define it as two challenges to be addressed:
>  1) How to instrument the code and collect the data on a
>  native system, and
>  2) the fact that the gdb side is only written to handle
>  the remote target.
>
>  I would certainly love to see a native implementation
>  happen, and it would be fair to say that #2 is my fault,
>  so if somebody were to seriously undertake solving #1,
>  I would undertake to at least help work on #2...
>
>  Michael
>
>
>

Re: Tracepoints functionality for local targets

[Michael Snyder]

On Wed, 2008-02-27 at 09:08 +0100, Lokesh Gupta wrote:
> Hello,
> 
> Can't we take the following approach to this issue:
> 
> - Treat tracepoints as 'silent' breakpoints such that when the user
> sets tracepoints actually a breakpoint is inserted with a special
> property called as 'trace-silent'
> - During execution, when this breakpoint is hit, the usual GDB flow of
> handling the breakpoint comes into picture, GDB gets control, it
> collects all required data from the current frame ($regs,$args,$locals
> as requested by user for this tracepoint), and then silently continues
> the execution because it can identify it as a special breakpoint with
> the property of 'trace-silent'

This would definitely be one possible implementation.

By the way, the tracepoint framework was designed to be largely
implementation-independent, so that to a large extent it should 
be able to work with any of a number of different implementations.

What you suggest would have the advantage of being pretty 
general (should work with native/remote/sim/whatever), but
it has one big disadvantage -- as soon as gdb becomes involved
with the tracepoint data collection, you lose the advantage of
speed.

Part of the goal of tracepoints is to be as un-intrusive as
possible -- get in and get out without interfering with the
timing of the target system any more than necessary.  If
you're willing to compromise that goal, then you can do
things as you describe.

There's also no reason we can't have multiple tracepoint
implementations in place at the same time, so long as we
have a way of selecting between them.  Eg. turn off the
general-but-slow method if you have available a 
target-specific-but-fast method.

Re: Tracepoints functionality for local targets

[Nicholas Mc Guire]

>
> Can't we take the following approach to this issue:
>
> - Treat tracepoints as 'silent' breakpoints such that when the user
> sets tracepoints actually a breakpoint is inserted with a special
> property called as 'trace-silent'

that is what the current implementation actually does except that we put
the tracepoint into a seperate list of breakpoint instead of changing the
description of the currently in use breakpoints. Basically this was done
this way because working your way through the path of the breakpoint code
atleast in gdbserver was a complete mess.

> - During execution, when this breakpoint is hit, the usual GDB flow of
> handling the breakpoint comes into picture, GDB gets control, it
> collects all required data from the current frame ($regs,$args,$locals
> as requested by user for this tracepoint), and then silently continues
> the execution because it can identify it as a special breakpoint with
> the property of 'trace-silent'

The main difference is that you need to add gdb bytecode to the picture
because variables or expressions can't directly be resolved as at time of
defining the variable you don't actually have access to the target - that
is taken care by translating expressions to bytecode and sending the
bytecode to the target that then executes it on hitting a tracepoint and
stores the result only.

> - The data which is collected by an enabled tracepoint is stored as a
> 'snapshot' which is a node in a linked list of all snapshots collected
> during program execution. This linked list could be used for the
> implementation of the tfind like functions to provide necessary
> information to the user.

thats just what the current implementation does - see tp.c and list.c in
the tracpoint code.

hofrat