Re: outputs of GCC JIT?

[David Malcolm <dmalcolm@redhat.com>]

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).