public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: outputs of GCC JIT?
  2015-01-01  0:00 outputs of GCC JIT? Basile Starynkevitch
@ 2015-01-01  0:00 ` David Malcolm
  0 siblings, 0 replies; 2+ messages in thread
From: David Malcolm @ 2015-01-01  0:00 UTC (permalink / raw)
  To: Basile Starynkevitch; +Cc: jit

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* outputs of GCC JIT?
@ 2015-01-01  0:00 Basile Starynkevitch
  2015-01-01  0:00 ` David Malcolm
  0 siblings, 1 reply; 2+ messages in thread
From: Basile Starynkevitch @ 2015-01-01  0:00 UTC (permalink / raw)
  To: jit

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

Regards.

-- 
Basile Starynkevitch         http://starynkevitch.net/Basile/
France

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-07-09 13:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-01  0:00 outputs of GCC JIT? Basile Starynkevitch
2015-01-01  0:00 ` David Malcolm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).