From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23179 invoked by alias); 17 Dec 2018 17:01:38 -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 23037 invoked by uid 89); 17 Dec 2018 17:01:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=limitations, hopes, gdbserver, D*ca X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Dec 2018 17:01:35 +0000 Received: from horde5.polymtl.ca (horde5.polymtl.ca [132.207.4.156]) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id wBHH1WhQ017038; Mon, 17 Dec 2018 12:01:32 -0500 Received: from dyn40.dorsal.polymtl.ca (dyn40.dorsal.polymtl.ca [132.207.72.40]) by www.imp.polymtl.ca (Horde Framework) with HTTP; Mon, 17 Dec 2018 17:01:32 +0000 Date: Mon, 17 Dec 2018 17:01:00 -0000 Message-ID: <20181217170132.Horde.NLSib2h5TihniJpAT8HIP5J@www.imp.polymtl.ca> From: Paul Naert To: tom@tromey.com Cc: gdb@sourceware.org Subject: Re: [Compile] Inserting compiled code via jumps References: <20181212160933.Horde.zgKx70qWwfqOpGUV4Dq7x5_@www.imp.polymtl.ca> <87pnu25rkk.fsf@tromey.com> In-Reply-To: <87pnu25rkk.fsf@tromey.com> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00009.txt.bz2 Hi, The idea is similar to fast breakpoints conditions, as gdb would need to patch in a jump to the compiled code directly or via a trampoline. Here is an example of how it could be used : (gdb) fcompile file snippet.c test.c:8 // snippet.c is compiled via gcc. It could contain a call to an trace collector function for instance // The instruction corresponding to line 8 of source file test.c is replaced by a jump to a trampoline // In the trampoline we call _gdb_expr_(), and then execute the instruction that we replaced, corrected for displacement (gdb) run // The code from snippet.c is executed every time we hit line 8 of test.c This would directly encompass fast breakpoint conditions, using a snippet like "if(cond) __asm__("int3");". NB: this does not work right now because gdb does not debug the inserted snippet, but it should when injected via a jump. The code for patching in the jump is located in gdbserver, I think there is no use for dyninst for this. I am currently trying to migrate what is necessary to a common directory. If you need any more information let me know. Thanks, Paul Tom Tromey wrote : >>>>>> "Paul" == Paul Naert writes: > > Paul> I am a masters student and I would like to devote my research to > Paul> improving GDB's GCC Compile and Execute by adding the possibility to > Paul> jump directly to the compiled code without having to hit a breakpoint. > > Paul> The idea is to reuse the same principle that was used in fast > Paul> tracepoints to insert code in a compiled program, except that instead > Paul> of jumping to GDB's collector function we would execute the code > Paul> compiled by GCC each time we hit the selected instruction. > > I am not sure I really understand the idea. > > With the "compile" command, we had hopes of someday extending it to > either allow fast breakpoint conditions (by compiling the breakpoint > condition and patching the process); or to allow fix-and-continue > (recompiling a single function and inserting it). > > Is your idea like one of these? If it's different, could you maybe show > an example of how a user would use it? > > Paul> - Has someone already worked on this ? On the wiki page there are > Paul> mentions to future projects that seem related (fast breakpoint > Paul> conditions most notably) > > As far as I know nobody is working on it. > > Paul> - Do you see any reason why that would not work that I missed, > Paul> except for the limitations of the existing Compile project? > > I think it's entirely possible. I think the main issues involve the > patching -- figuring out how to replace instructions. Maybe dyninst > could be used to help with the rewriting, or maybe it can be done purely > in gdb. > > thanks, > Tom