From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26698 invoked by alias); 11 Feb 2015 13:53:58 -0000 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 Received: (qmail 26688 invoked by uid 89); 11 Feb 2015 13:53:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 Feb 2015 13:53:55 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDrqAe006336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 11 Feb 2015 08:53:52 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1BDro9G012692; Wed, 11 Feb 2015 08:53:50 -0500 Message-ID: <54DB5EED.3090201@redhat.com> Date: Wed, 11 Feb 2015 13:53:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Muldoon , "Jose E. Marchesi" , gdb Subject: Re: C injection GDB project References: <877fvopv7x.fsf@gnu.org> <54DB37D0.1010108@redhat.com> <54DB4767.4060006@redhat.com> In-Reply-To: <54DB4767.4060006@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00020.txt.bz2 On 02/11/2015 12:13 PM, Phil Muldoon wrote: > On 11/02/15 11:06, Pedro Alves wrote: >> On 02/11/2015 11:02 AM, Jose E. Marchesi wrote: >>> >>> I would like to work in the C injection GDB project. > > Hi > > I CC'd the GDB mailing list and trimmed some of the post. I hope you > do not mind. Pedro asked me to reply to you on this interest. > > You've picked an excellent time to show interest! Phase one is > complete and we are just about starting phase two. What is phase two? > C++! > > The current status of the project is that the C parts of the injection > process have been checked into both GCC and GDB. The GCC parts will be > released in GCC 5. The GDB parts in the next GDB release. > > A brief overview of the mechanics and methods of the project can be > found here: > > https://sourceware.org/gdb/wiki/GCCCompileAndExecute#preview > > There is also a talk given in the 2014 GNU Cauldron. You can find it > here: > > https://www.youtube.com/watch?v=YQATnypexbY > > All discussion related to the project should be on gdb@sourceware.org > and all patches to gdb-patches@sourceware.org > > For historical review, the GDB parts of the project can be found here: > > https://github.com/tromey/gdb/commits/gdbjit/gd > > And the GCC bits here: > > https://github.com/tromey/gcc/tree/submit/compile > > Note both of those branches are now defunct. All the code contained in > them is checked in to the relevant upstream projects. I provide them > purely for archaeological purposes. > > The people who work mostly on this project are: me, Jan Kratochvil > and Tom Tromey. Tom previously lead the > effort, but has now moved on to other fun stuff. There have been many > others who contributed in one way or another, not least of all > the reviewers. Alas, they are too numerous to list here. > > A TODO (in summary): > > - Write the C++ plug-in for GCC. Re-architect and reuse the C plug-in > code wherever possible. > > - Teach GDB to tell GCC about C++ types. > > Those two will take a lot of time. We have not started yet. > > Eventually we want to provide: > > - compile print > - compile printf > - compile cond (or some other interface for conditional breakpoints) > - Maybe a fix-and-continue interface > - Maybe intelligently design a way GDB can use GCC for parsing > expressions in some case. In addition (or maybe in expansion of that last point): - Fully replace GDB's C and C++ parsers by calling into GCC/G++'s parsers. IOW, make "(gdb) print EXPR" (and wherever else an EXPR is evaluated) use gcc's frontend to parse EXPR. That can of course be phased in, with e.g. a new "print -inject" switch to force it, and a new global setting the user can use to select the mechanism GDB should use to evaluate the expression. - Related, to fully replace GDB's own built in parsers, we'll need to be able to evaluate expressions using GCC's frontends, but without injecting code in the inferior and calling it. Function calls can potentially corrupt more an already corrupt inferior, so best avoid that by default, and there's also debugging core dumps, which obviously can't execute code. My idea for that would be to make the GCC frontend stop compilation at the gimple level, and then add a gimple interpreter (gimple == gcc's IR) to the gcc plugin, which would callback into GDB whenever it needed to read memory or registers out of the inferior. I'd be thrilled if someone picked up this project! Thanks, Pedro Alves