From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1159 invoked by alias); 20 Apr 2016 14:49:43 -0000 Mailing-List: contact infinity-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: infinity-owner@sourceware.org Received: (qmail 1148 invoked by uid 89); 20 Apr 2016 14:49:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:infinit, Gary, separation, Hx-languages-length:1738 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Date: Wed, 20 Apr 2016 14:49:00 -0000 From: Gary Benson To: infinity@sourceware.org Subject: Infinity client library first look Message-ID: <20160420144929.GA17505@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Red Hat UK Ltd, 64 Baker Street, 4th Floor, W1U 7DF, UK. Registered in England and Wales (3798903) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 20 Apr 2016 14:49:31 +0000 (UTC) X-SW-Source: 2016-q2/txt/msg00000.txt.bz2 Hi all, This past few weeks I've been working on an Infinity client library for programs to use to access and execute Infinity notes. It's very alpha at the moment, but if you'd like to build and execute an Infinity note there's instructions at . There's very little documentation as yet (and certainly no API/ABI guarantees!) but you can see the shape of the library and the kind of API to expect. The "tlsdump_process" function in examples/tlsdump.c and the "process_notes" function it calls is the core of it all: 1. Use i8x_ctx_new to create a context. 2. Use i8x_note_new_from_buf, i8x_func_new_from_note and i8x_ctx_register_func to load, compile and register note functions into the context. (3. Use i8x_inferior_new to create a representation of the inferior process you're accessing. This isn't present yet, it's the NULL in the arguments of i8x_xctx_call below.) 4. Use i8x_xctx_new to create an execution context. 5. Use i8x_ctx_get_funcref to get references to the functions you're going to call. 6. Use i8x_xctx_call to execute the note functions. The point of the context/inferior/execution context separation is to allow for systems where one executable+solibs spawns multiple inferior processes, and for multithreaded clients. * one executable+solibs maps to one i8x_ctx * one inferior process maps to one i8x_inferior * one thread in your client maps to one i8x_xctx. Full multithreaded support may not exist straight away (GDB doesn't need it) but I didn't want to lay out an API/ABI that could never support it. I've never written a library before, so please hit me with your questions and concerns! Cheers, Gary -- http://gbenson.net/