about header file parsing

[akrl]

Marc Nieper-Wißkirchen <marc@nieper-wisskirchen.de> writes:

> [...]
>
>> > 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?
>>
>> It depends on the patch :)
>>
>> I'm not opposed on principle; gcc_jit_context_add_command_line_option
>> already has the caveat:
>>   "Note that only some options are likely to be meaningful"
>> in the docs, and it's already something of a loophole for doing things
>> that I haven't though of.
>>
>> I wonder if we'd need to have some distinction between options for the
>> compiler vs options for the driver (maybe introduce a new entrypoint
>> for driver options?).  IIRC cc1 will complain with a fatal error if it
>> gets driver-specific options.
>
> This is probably the saner approach. Having two entrypoints is
> definitely no less powerful than having just one.
>
> What do you think of gcc_jit_context_add_driver_option? Or,
> alternatively, gcc_jit_context_compile_with_options and
> gcc_jit_context_compile_to_file_with_options?
>
>> > 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.
>>
>> It sounds like you want have LTO against a "jit-obstack.so" (or
>> somesuch) when the driver converts jit-generated assembler to its .so
>
> Actually, I think I want to link against jit-obstack.o. Thus my
> earlier question, whether supplying "-fuse-linker-plugin -flto
> jit-obstack.o" to the driver is possible.
>
>> This sounds really interesting; I've never tried LTO with libgccjit.
>> It might just work, but I suspect you might run into unexpected issues
>> of some kind.  Seems like a fun thing to experiment with.
>
> We should do as this would allow wrapper libraries like the from the
> example above and will solve many of the problems raised in this
> thread.
>
> [...]
>
> Marc
>

Hi,
today I've wrote a patch that adds GCC_JIT_STR_NEEDED_LIBRARIES to
gcc_jit_str_option.
This was to specify a space separated list of the libraries to link against.
I was going to submit the patch for review but this solution seams to be
more general.
If we agree on an interface I propose my self to do the patch in order
to have the occasion to setup the whole process.

Bests

  Andrea

-- 
akrl@sdf.org