Re: about header file parsing

[Marc Nieper-Wißkirchen <marc@nieper-wisskirchen.de>]

Am Do., 10. Jan. 2019 um 09:21 Uhr schrieb Marc Nieper-Wißkirchen
<marc@nieper-wisskirchen.de>:
>
> Am Di., 8. Jan. 2019 um 22:16 Uhr schrieb Basile Starynkevitch
> <basile@starynkevitch.net>:
>
> [...]
>
> > Still another thing could be to use LTO: you'll compile your C file with
> > GCC using -flto, you'll do LIBGCCJIT things, and the final executable
> > sould be compiled and linked with -flto.
>
> Is using:
>
> gcc_jit_context_add_command_line_option (ctxt, "-flto helper.o");
>
> supported to have the object generated by libgccjit statically linked
> with the object helper.o before libgccjit emits the final dynamic
> library? (Let's assume that helper.o has been compiled with -flto.)

[...]

Having taken a look at the source code of libgccjit, it seems that the
command line options set by `gcc_jit_context_add_command_line_option'
are not passed to the driver used to compile the generated 'fake.s':
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/jit/jit-playback.c?view=markup#l2407

Dave, would you agree to add a patch that reuses the command line
options set by `gcc_jit_context_add_command_line_option' when the
driver is invoked? In particular, one would want to be able to
override `-fno-use-linker-plugin'.

Here is a use case. Assume that jitted code wants to use <obstack.h>
(just to give an example). The struct obstack is opaque, and many
"functions" are implemented as macros. To solve the issues raised in
this thread, I would write a jit-obstack.c like the following:

#include <stdalign.h>
#include <xalloc.h>
#include <obstack.h>

#define obstack_chunk_alloc xmalloc
#define obstack_chunk_free free

struct jit_obstack
{
  alignas (alignof (struct obstack)) char p[sizeof (struct obstack)];
};

int
jit_obstack_init (struct jit_obstack *op) __attribute__ ((visibility
("hidden")))
{
  return obstack_init ((struct obstack *) op);
}
...

The jitted code would then access obstacks solely through
jit-obstack.c. By doing so, we do not have to look at the internals of
<obstack.h> (which may be different on the programmer's and the target
system!) and we do not have to recreate opaque structures in a
gcc_jit_context.

However, the code will only run as fast as C directly including
<obstack.h> if and only if we can use link-time optimization when
creating the jitted shared object through libgccjit.

-- Marc