From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3396 invoked by alias); 9 Jul 2015 13:52:44 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 2559 invoked by uid 89); 9 Jul 2015 13:52:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS,UNSUBSCRIBE_BODY autolearn=no 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 Message-ID: <1436449490.24803.125.camel@surprise> Subject: Re: outputs of GCC JIT? From: David Malcolm To: Basile Starynkevitch Cc: jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <20150709104325.GA789@ovh.starynkevitch.net> References: <20150709104325.GA789@ovh.starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-SW-Source: 2015-q3/txt/msg00051.txt.bz2 On Thu, 2015-07-09 at 12:43 +0200, Basile Starynkevitch wrote: > Hello All, > > In my partial understanding, gccjit is outputing either error messages or logging. > > The log file can be set with gcc_jit_context_set_logfile > > But what about the error messages? > > Perhaps we are lacking some > > gcc_jit_context_set_errorfile(gcc_jit_context*ctxt, FILE*errfile, int flags); > > Can we be sure that GCCJIT does never write to stdout or stderr? > > A typical usecase where we don't want that is some CGI or FastCGI web-application... > (which reserves stdout & stderr for their own use). In theory an error should not occur; it's fatal to the gcc_jit_context *, no further compilation can happen on that context. I guess it could be handy to be able to send the error messages somewhere other than stderr, for flexibility if nothing else. A service that logs to its own logfile, or to syslog might want to send error messages there, and a FILE * might not be generic enough. Maybe the API could look like this: typedef void (*gcc_jit_error_handler) (gcc_jit_context *ctxt, gcc_jit_location *loc, const char *msg, void *user_data); extern void gcc_jit_context_set_error_handler (gcc_jit_context *ctxt, gcc_jit_error_handler callback, void *user_data); with a NULL callback meaning "default behavior", or maybe also exposing: extern void gcc_jit_default_error_handler (gcc_jit_context *ctxt, gcc_jit_location *loc, const char *msg, void *user_data); This has the side-benefit of allowing users to easily put a breakpoint on this callback in a debugger. (I wondered also if there's a security risk in having messages go to stderr for CGI scripts, but I think that any place where an attacker could try to discern something from the error messages is also likely somewhere where the attacker is already able to inject arbitrary machine code, so it's already "game over" at that point).