Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Naert <paul.naert@polymtl.ca>
To: tom@tromey.com
Cc: gdb@sourceware.org
Subject: Re: [Compile] Inserting compiled code via jumps
Date: Mon, 17 Dec 2018 17:01:00 -0000	[thread overview]
Message-ID: <20181217170132.Horde.NLSib2h5TihniJpAT8HIP5J@www.imp.polymtl.ca> (raw)
In-Reply-To: <87pnu25rkk.fsf@tromey.com>

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 <tom@tromey.com> wrote :

>>>>>> "Paul" == Paul Naert <paul.naert@polymtl.ca> 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




      parent reply	other threads:[~2018-12-17 17:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 16:09 Paul Naert
     [not found] ` <87pnu25rkk.fsf@tromey.com>
2018-12-17 17:01   ` Paul Naert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181217170132.Horde.NLSib2h5TihniJpAT8HIP5J@www.imp.polymtl.ca \
    --to=paul.naert@polymtl.ca \
    --cc=gdb@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox