From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10520 invoked by alias); 11 Jan 2013 07:29:33 -0000 Received: (qmail 10512 invoked by uid 22791); 11 Jan 2013 07:29:32 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.nus.edu.sg (HELO imsva05.stf.nus.edu.sg) (137.132.14.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Jan 2013 07:29:26 +0000 Received: from imsva05.stf.nus.edu.sg (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 572A010062 for ; Fri, 11 Jan 2013 15:26:28 +0800 (SGT) Received: from smtp.nus.edu.sg (unknown [137.132.21.157]) by imsva05.stf.nus.edu.sg (Postfix) with ESMTP id 3B55B1005E for ; Fri, 11 Jan 2013 15:26:28 +0800 (SGT) Received: from r-144-189-28-172.comp.nus.edu.sg ([172.28.189.144]) by smtp.nus.edu.sg over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jan 2013 15:28:16 +0800 Subject: Re: Tracepoints (and python) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Marc_Br=FCnink?= In-Reply-To: Date: Fri, 11 Jan 2013 07:29:00 -0000 Cc: Tom Tromey , gdb Content-Transfer-Encoding: quoted-printable Message-Id: <728CB725-036A-4285-8FCE-3A1D6705926D@nus.edu.sg> References: <464A745A-AA80-4485-820E-64C4D01A270C@nus.edu.sg> <87k3scn69b.fsf@fleche.redhat.com> <87k3rv5wab.fsf@fleche.redhat.com> To: Doug Evans X-TM-AS-MML: No X-TMASE-Version: IMSVA-8.2.0.1580-7.0.1014-19546.005 X-TMASE-Result: 10--27.430200-5.000000 X-TMASE-MatchedRID: RfRf601lRZGDCdFIVzIzHcM+NV+TRYVZSSQ7jOqms06/W88A/PbYWUCr r/LkAQ46Fp7kniXxovM4g0s+Thx5gk40MAL5wmzY46DPDdEl/wcLd3u89FoqUdaZQXm25YCOvgd LSTYd46hJJReS9JUB3CLlm5uWqGjWY9zPIyp0I9em7BQRVhMI5rvSniSB5hLE7DzBuedLDxu2Mc ZY43zJ4/FJXtgF4GFL4Tno5sC0gjw6xUU9X/Tgtvwwj3l+qWTBScLzjXCP5LQksSBZTGCrwoRgZ NP+6bISxEHRux+uk8jpP8tMOyYmaA== X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00038.txt.bz2 On Jan 3, 2013, at 1:44 AM, Doug Evans wrote: > On Wed, Jan 2, 2013 at 10:28 AM, Tom Tromey wrote: >> Marc> 1. Is there any technical reason why tracing is only possible on >> Marc> remote targets? Or is is "just" not implemented for anything else. >>=20 >> Tom> I think the only reason is that nobody has done it. >>=20 >> Doug> This is part of gdb/gdbserver feature parity desires right? >>=20 >> It is on the list on the wiki, but I think just to mention it as a >> difference. We (meaning Red Hat) plan to tackle most of the items on >> that list, but I don't think this is one we are going to do. >=20 > [Sorry for the resend, previous one got sent as text/html.] >=20 > Thanks. >=20 > For clarity's sake for Marc, > what's needed isn't so much an implementation as a (pretty > significant) refactor. Interesting. Actually I am trying to implement a rudimentary application tr= acer using the python interface. So far I have simply used breakpoints. It = works like a charm but is obviously very slow. Thus, I want to switch to tr= acepoints. Having access to tracepoints during native debugging would be ni= ce but is not necessary. This is a point for my personal wish list. Another issue is the trace buffer. It would be nice to get a notification a= s soon as the trace buffer is full. Currently gdbserver does not sent one (= assuming gdb is connected), does it? Marc