Re: GNU Cauldron talk on libgccjit

[David Malcolm <dmalcolm@redhat.com>]

On Wed, 2014-07-30 at 14:31 -0300, Carlos Costa wrote:
> Hi David, thanks for share it. 
> 
> 
> Please, I would like to make you a somewhat dummy question (so forgive
> my ignorance). In the slide #42 [1], you mention:
> 
> 
>    Assembler as a shared library?
>    Currently the library:
>    writes out a .s file to a tempdir
>    invokes another "gcc" on it to convert it to a .so
>    dlopen on the .so and then dlsym
> 
> 
> What if we mmap() the .s file in a executable memory region from the
> heap and then call it, processing the return? Do you think this could
> be used instead of dlopen a .so to execute?

I'm not sure I fully understand your idea; sorry.

Sorry if my slide was unclear.  The issue is that we want executable
pages of machine code in our address space, whereas gcc currently merely
emits assembler to a .s file.

Hence we need:

(A) to convert that assembler into machine code (right now libgccjit
does that by invoking another gcc(!), which (i) runs gas to turn the .s
into a .o, and (ii) runs the linker to turn the .o into a .so
[implemented in gcc/jit/internal-api.c in the method
playback::context::compile]


(B) to have that machine code mapped into the process' address space, as
executable pages.  Right now libgccjit does that by dlopen-ing the .so
file built in step (A) [also implemented within internal-api.c:
playback::context::compile]


(C) if we're being debugged, to let the debugger know about the new code
in memory, and the relevant debug data.  This happens "for free" right
now since gdb already handles .so files being dlopen-ed; gdb does have
an interface for telling it about other lower-level ways of mapping in
code, so we'd have to use that if we go with a more direct route.


The current approach is a kludge, and it shows up as a significant
portion of the profile (I've seen it take up to 50% of the wallclock
time for a gcc_jit_context_compile call).  However it's an
implementation detail hidden behind the API, so we can fix it.  A more
efficient approach would be an assembler as a shared library that could
give us (A) and (B) directly.

> Thanks in advance,
> Carlos.
> 
> 
> [1] https://dmalcolm.fedorapeople.org/presentations/cauldron-2014/jit/#42 
> 
> 
> On Wed, Jul 30, 2014 at 11:39 AM, David Malcolm <dmalcolm@redhat.com>
> wrote:
>         I gave a talk on the JIT library at the GNU Tools Cauldron
>         2014 meeting
>         in Cambridge UK a week and a half ago:
>         
>         "Just-In-Time compilation using GCC (libgccjit.so)"
>         
>         HTML slides can be seen at:
>         http://dmalcolm.fedorapeople.org/presentations/cauldron-2014/jit/
>         
>         The source code used for generating the HTML slides:
>         https://github.com/davidmalcolm/2014-cauldron-jit-talk/blob/master/source/index.rst
>         
>         (built using Sphinx, and hieroglyph.io)
>         
>         I'm not sure if the talk was recorded.
>         
>         Dave
>         
> 
>