Message ID | CAEvRbeo3rskVCPydMPZ22ByY2hz_NN6tmpprxaXRV==mQO68wQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
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
On 12 February 2014 00:52, David Malcolm <dmalcolm@redhat.com> wrote: > 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!] Yep i still have GCC copyright assignment. > Excellent! Looks promising - though it looks like the backend is all > stubbed out at the moment. Yeah only got started on it yesterday. Just need something to work with the jit api to test and look to add features for. > > 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. > Yeah good point. > 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. > Thats a good idea. >> 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. > Yeah i was looking into it at the time and found, that trying to make gas compile to a .so was a bit of a nightmare i couldn't get the Makefile.am to regenerate its a funny autotools setup. But found aparently libopcodes: "The opcodes library contains functionality to assemble and disassemble human readable assembly language to and from raw machine code. " http://www.toothycat.net/wiki/wiki.pl?Binutils Might be something to look into. --Phil
On Wed, 2014-02-12 at 09:53 +0000, Philip Herron wrote: > On 12 February 2014 00:52, David Malcolm <dmalcolm@redhat.com> wrote: > > 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!] > > Yep i still have GCC copyright assignment. Thanks; I've committed and pushed this to the dmalcolm/jit branch (with a ChangeLog.jit entry).
From c0c1c3d55ad707ef5c62199791acabd1ceea6858 Mon Sep 17 00:00:00 2001 From: Philip <redbrain@gcc.gnu.org> Date: Tue, 11 Feb 2014 16:46:15 +0000 Subject: [PATCH] Add install hook --- gcc/jit/Make-lang.in | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in index 17d27ca..0a468da 100644 --- a/gcc/jit/Make-lang.in +++ b/gcc/jit/Make-lang.in @@ -85,7 +85,9 @@ jit.srcman: # # Install hooks: -jit.install-common: +jit.install-common: installdirs + $(INSTALL_PROGRAM) libgccjit.so $(DESTDIR)/$(libdir)/libgccjit.so + $(INSTALL_PROGRAM) $(srcdir)/jit/libgccjit.h $(DESTDIR)/$(includedir)/libgccjit.h jit.install-man: -- 1.8.3.2