From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12320 invoked by alias); 18 Feb 2014 21:58:51 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 12311 invoked by uid 89); 18 Feb 2014 21:58:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=unavailable version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2014 21:58:49 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1ILwjJ1018991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Feb 2014 16:58:45 -0500 Received: from [10.3.236.181] (vpn-236-181.phx2.redhat.com [10.3.236.181]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1ILwi9D019219; Tue, 18 Feb 2014 16:58:44 -0500 Message-ID: <1392760637.7367.80.camel@surprise> Subject: Re: Assembler as shared library From: David Malcolm To: Philip Herron Cc: nick clifton , binutils@sourceware.org, jit@gcc.gnu.org Date: Tue, 18 Feb 2014 21:58:00 -0000 In-Reply-To: References: <52FE329F.7010001@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00109.txt.bz2 [existing thread uses top-posting, so am going with that] Philip: thanks for working on this. Some context for binutils people: I've been working on an experimental branch of gcc that can be built as a shared library for just-in-time compilation: http://gcc.gnu.org/wiki/JIT The GCC JIT codebase can take client API calls and give assembler, rather than machine code. Right now I have an ugly hack that calls out to (another) gcc to use gcc's harness logic to invoke programs to turn the .s file into a .so (via a .o), then links it into memory. IIRC, this hack takes about half the wallclock, though I don't know to what extent it's the expense of execing subprocesses vs the inherent work of the .s to machine code, and ELF manipulation. So it would be nice to have the existing binutils code be available as a library that can turn either a .s file (or even an in-memory string) into machine code. Hence my interest in the GNU Assembler as a shared library (although as I understand it that's only half the battle - turning it into a DSO would be further effort, and ideally we could skip much of this, since it's all in-process). >From the JIT's point of view, what I need is something that can repeatedly be invoked within one process (perhaps from different threads), so I think state management is going to be an issue here. Last time I looked at the gas source code, my recollection is that there are quite a few global variables. One way to tackle this is to get rid of all globals, moving them all into some kind of "context" struct. Another way is to put a big mutex around the library, and to purge all state when done. I'm using a similar approach in gcc, and the latter especially within my "jit" branch. An approach to take might be an outside-in one: what should the API look like? From the libgccjit perspective, perhaps something like this would be good: extern gas_context * gas_context_acquire (void); extern void gas_context_release (gas_context *ctxt); extern void gas_context_set_input_file (gas_context *ctxt, const char *path); extern void gas_context_set_output_file (gas_context *ctxt, const char *path); extern int gas_context_assemble (gas_context *ctxt); ??? (caveat: very much a first iteration, no idea if the above is sane, though there's a stylistic resemblance to the libgccjit.h API) Hope this is helpful Dave On Mon, 2014-02-17 at 16:54 +0000, Philip Herron wrote: > Hey all > > This is my initial patch it creates a shared library out of gas and > installs the necessary headers along side it. I am trying to work out > how to use it so far need more time tracing through the code to figure > it out but so far i am been copying and pasting bits and pieces to get > this so far as a client program: > > #include > #include > #include > > #include > #include > #include > > char * out_file_name; > > int main (int argc, char **argv) > { > printf ("trying...\n"); > out_file_name = strdup ("./ninja"); > > bfd_init (); > md_begin (); > > symbol_begin (); > frag_init (); > subsegs_begin (); > read_begin (); > input_scrub_begin (); > expr_begin (); > > output_file_create (out_file_name); > > dot_symbol_init (); > > text_section = subseg_new (TEXT_SECTION_NAME, 0); > data_section = subseg_new (DATA_SECTION_NAME, 0); > bss_section = subseg_new (BSS_SECTION_NAME, 0); > > subseg_new (BFD_ABS_SECTION_NAME, 0); > subseg_new (BFD_UND_SECTION_NAME, 0); > reg_section = subseg_new ("*GAS `reg' section*", 0); > expr_section = subseg_new ("*GAS `expr' section*", 0); > subseg_set (text_section, 0); > > read_a_source_file ("./t.s"); > write_object_file (); > > free (out_file_name); > > return 0; > } > > $ gcc -g -O2 -Wall test.c -o test -I/opt/binutils/include > -L/opt/binutils/lib -lgas -lbfd > > Its definitely not right but demonstrates i am calling into normal gas > things. Hope to get more working soon and i will probably need to make > some wrapper code as this although i am doing it completely wrong is > fairly involved. I would great if i could get some feedback i reckon > this patch is probably going to break some stuff. > > Thanks i hope i can get something more use-able soon. > > --Phil > > On 14 February 2014 17:06, Philip Herron wrote: > > Ah thanks! I have a github repo: > > > > https://github.com/redbrain/binutils-gdb/tree/libasm > > > > It now builds libasm.la which as is built off now and as seems to > > work. So i think i have the first stages of this working. I am > > #ifdefing out the main so far and need to make a libgas.h so we can > > use this in David Malcoms jit. > > > > On 14 February 2014 15:13, nick clifton wrote: > >> Hi Philip, > >> > >> > >>> But i can find any where to start to make a little mini assembler > >>> using libopcodes. > >> > >> > >> Take a look at gas/doc/internals.texi, especially the section on GAS > >> processing. > >> > >> Essentially you will need to provide library routines that emulate what is > >> done in gas/as.c:main(). > >> > >> Cheers > >> Nick > >> > >>