This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Simple install hook
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Philip Herron <redbrain at gcc dot gnu dot org>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, jit at gcc dot gnu dot org
- Date: Tue, 11 Feb 2014 19:52:43 -0500
- Subject: Re: Simple install hook
- Authentication-results: sourceware.org; auth=none
- References: <CAEvRbeo3rskVCPydMPZ22ByY2hz_NN6tmpprxaXRV==mQO68wQ at mail dot gmail dot com>
On Tue, 2014-02-11 at 16:51 +0000, Philip Herron wrote:
[adding the jit@gcc.gnu.org ML to the CC]
> Added install hook:
Thanks!
I don't know that this is needed for a 3-line patch, but have you done
the copyright assignment paperwork for GCC contribution? (I hope to
merge my branch into gcc trunk at some point). [Also, I'd love to have
more, larger, patches from you for the jit branch!]
> /opt/gjit/bin/gcc -g -O2 -Wall t.c -o test -I/opt/gjit/include
> -lgccjit -L/opt/gjit/lib
>
> Compiles the helloworld examples correctly and it runs instead of
> pointing to my gcc build dir. Am working on getting more involved with
> this and started:
>
> https://github.com/redbrain/spy
>
> Its only just starting to parse stuff but a kind of C/Python kind of
> language using gcc as a JIT might be interesting kind of dynamic
> language for C that can call C libs safely and easily is the idea.
> Mostly just so i can see where to help out in the jit front-end.
Excellent! Looks promising - though it looks like the backend is all
stubbed out at the moment.
Note that the JIT API isn't frozen yet. I try to remember to add "API
change" to the subject line when posting my commits, but I don't always
remember.
Let me know if you have any questions on how the JIT API works - or
input on how it *should* work.
FWIW I've been experimentally porting GNU Octave's LLVM-based JIT to
using libgccjit, and finding and fixing various issues in the latter on
the way - that's been driving a lot of the patches to the jit branch
lately.
> Was also considering some kind of libopcodes work to assemble the code
> in memory instead of creating a .so in /tmp. Not sure if i know what i
> am doing enough there but it might be more elegant for stuff using
> this front-end.
My thinking here was that the core code of the GNU assembler could gain
the option of being built as a shared library, and having to isolate
state in a "context" object, and we could try to hack the two projects
into meeting in the middle. Large amount of work though (and a
different mailing list), hence the crude .so hack for now.
> Am so impressed how well this works.
Cheers!
Dave