To help with debugging: dump a C-like representation to the given path, describing what’s been set up on the context.
If “update_locations” is true, then also set up gcc_jit_location information throughout the context, pointing at the dump file as if it were a source file. This may be of use in conjunction with GCC_JIT_BOOL_OPTION_DEBUGINFO to allow stepping through the code in a debugger.
To help with debugging; enable ongoing logging of the context’s activity to the given file.
For example, the following will enable logging to stderr.
gcc_jit_context_set_logfile (ctxt, stderr, 0, 0);
Examples of information logged include:
An example of a log can be seen here, though the precise format and kinds of information logged is subject to change.
The caller remains responsible for closing logfile, and it must not be closed until all users are released. In particular, note that child contexts and gcc_jit_result instances created by the context will use the logfile.
There may a performance cost for logging.
You can turn off logging on ctxt by passing NULL for logfile. Doing so only affects the context; it does not affect child contexts or gcc_jit_result instances already created by the context.
The parameters “flags” and “verbosity” are reserved for future expansion, and must be zero for now.
To contrast the above: gcc_jit_context_dump_to_file() dumps the current state of a context to the given path, whereas gcc_jit_context_set_logfile() enables on-going logging of future activies on a context to the given FILE *.
Write C source code into path that can be compiled into a self-contained executable (i.e. with libgccjit as the only dependency). The generated code will attempt to replay the API calls that have been made into the given context.
This may be useful when debugging the library or client code, for reducing a complicated recipe for reproducing a bug into a simpler form. For example, consider client code that parses some source file into some internal representation, and then walks this IR, calling into libgccjit. If this encounters a bug, a call to gcc_jit_context_dump_reproducer_to_file will write out C code for a much simpler executable that performs the equivalent calls into libgccjit, without needing the client code and its data.
Typically you need to supply -Wno-unused-variable when
compiling the generated file (since the result of each API call is
assigned to a unique variable within the generated C source, and not
all are necessarily then used).
Enable the dumping of a specific set of internal state from the compilation, capturing the result in-memory as a buffer.
Parameter “dumpname” corresponds to the equivalent gcc command-line
option, without the “-fdump-” prefix.
For example, to get the equivalent of -fdump-tree-vrp1,
supply "tree-vrp1":
static char *dump_vrp1;
void
create_code (gcc_jit_context *ctxt)
{
gcc_jit_context_enable_dump (ctxt, "tree-vrp1", &dump_vrp1);
/* (other API calls omitted for brevity) */
}
The context directly stores the dumpname as a (const char *), so
the passed string must outlive the context.
gcc_jit_context_compile() will capture the dump as a
dynamically-allocated buffer, writing it to *out_ptr.
The caller becomes responsible for calling:
free (*out_ptr)
each time that gcc_jit_context_compile() is called.
*out_ptr will be written to, either with the address of a buffer,
or with NULL if an error occurred.
|