GNU Cauldron talk on libgccjit

[Philip Herron]

Hey

Yeah this sounds pretty reasonable to me, i will try and work with the
binutils guys to get the --enable-host-shared option integrated and we
can go from there then. I got sort of stuck when trying to use the api
for a few days.

--Phil

On 31 July 2014 15:06, David Malcolm <dmalcolm@redhat.com> wrote:
> On Wed, 2014-07-30 at 18:38 +0100, Philip Herron wrote:
>> Great presentation I was meant to be there but stuff came up will
>> deffo need to make it to the next one!
>
> Thanks!  Cauldron was a lot of fun.
>
>> The assembler as shared library I have it in my github but i haven't
>> found how to work with the assembler yet the API seems pretty
>> complicated so I didn't really spend enough time on it but my new job
>> is more open source friendly so I am hoping to fix that :).
>
> This is
>   https://github.com/redbrain/binutils-gdb/tree/libasm
> right?
>
> A while back I had a go at trying to isolate state within gas, trying to
> pass a "context" object around, but rapidly ran into the realization
> that with that approach I was going to need to touch basically every
> function in the code.
>
> In the discussion about this at the Cauldron talk, someone pointed out
> that it isn't necessary to do it so cleanly for a first iteration: we
> can just have a big global mutex inside the assembler library guarding
> access to the pre-existing code/data, and then hide that behind a clean
> and minimal API for what's needed: access to buffers for the code, data,
> bss etc.
>
> So I think the steps here might be:
>
> (A) get support into binutils to support building gas as a library, with
> a configure-time option to enable -fPIC so that it can be built as a
> shared library (analogous to the --enable-host-shared option I added to
> gcc:
> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00637.html )
>
> Then, in parallel:
> (B.1) create a testbed client program to *use* the "libasm" API, perhaps
> a "run-asm" tool that can run a .s in-process (by assembling it to
> code).
> (B.2) write the libasm API, wrapping the existing assembler code
>
> [on the grounds that the only way to write a good API is to write
> something *using* that API at the same time, to get the rough edges off]
>
> Then:
> (C) port libgccjit to use the libasm API
>
> and eventually:
> (D) clean up the cruft within libasm, to eventually eliminate the mutex.
>
>
> Thoughts?
>
> Dave
>
>> > On 30 Jul 2014, at 15:39, 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
>> >
>
>