Thinking about libgccjit SONAME bump for gcc 5.2 (was Re: Four jit backports to gcc 5 branch)

[David Malcolm <dmalcolm at redhat dot com>]

On Mon, 2015-06-29 at 21:57 +0100, Dibyendu Majumdar wrote:
> On 29 June 2015 at 16:44, David Malcolm <dmalcolm@redhat.com> wrote:
> > I've gone over the changes to the gcc/jit and gcc/testsuite/jit.dg
> > directories in trunk since gcc 5 and backported the following 4 changes
> > from trunk to the gcc-5-branch:
> >
> > gcc-5-branch's r225123:
> >   * trunk's r222863 (8120405bda9bf222228b004e09b23e74eda57ae1, addition
> > of test-benchmark.c):
> >   https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00500.html
> >
> >
> > gcc-5-branch's r225125:
> >   * trunk's r224531 (8154a3514d5fc8067a6928531d5f61cd768bd62c
> > along with trunk's r224535 (1828cd755cf5e4a34d5638f543a059f3562ad957,
> > "PR jit/66539: Add parentheses as needed to
> > gcc_jit_object_get_debug_string"):
> >   https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01158.html
> >
> >
> > gcc-5-branch's r225127:
> >   * trunk's r224536 (3052eeefc4607a7147fdc55af6d86845890eb281, "jit: Add
> > a test for compound assignment"):
> >   https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01164.html
> >
> >
> > gcc-5-branch's r225129:
> >   * trunk's r224565 (6689f47f53079d76bbb051d3b5da9018c2e0161a,
> > "jit: Add missing type-checking to gcc_jit_{l|r}value_access_field")
> >   https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01211.html
> >
> >
> 
> Hi Dave - is this what will go into 5.2?

No, it's just the things that I've backported so far.

> If so, is the option to
> disable "unreachable" block validation going to be available?

I'm working on that, I know that it's important to Ravi (the deadline
for gcc-5.2 is Friday; 2015-07-03).

There's no good way to track enums in binary metadata, so I'm currently
thinking of this approach for the new options:

 extern void
 gcc_jit_context_set_bool_allow_unreachable_blocks (gcc_jit_context *ctxt,
                                                    int bool_value);

tagging it within the linker mapfile as being a new API.


I'm looking at ways to manage libgccjit API/ABI as per this thread:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01982.html
by transitioning to using symbol versioning, so that the linker can tag
subsets of libgccjit symbols in both libgccjit and in client binaries.

Adding symbol versioning will involve a SONAME bump (from libgccjit.so.0
to libgccjit.so.1), thus requiring anyone using libgccjit to recompile
for this one change (the transition to versioned symbols, that is);
hopefully we never need to bump the SONAME again.

Given that this is needed by Ravi I feel that this break is worth
backporting to gcc 5.2 (I'd rather do this one-time ABI break for the
benefit of specific users, than not do it out of concern for
hypothetical ones).

Hope this sounds sane.

As mentioned in that other thread, I'm wondering if linker experts could
advise on the sanity of using a feature-based naming scheme for symbol
map tags, rather than pure numbers?
e.g.
  LIBGCCJIT_ABI_INITIAL
  LIBGCCJIT_ABI_WITH_SWITCH_STATEMENTS
  LIGCCCJIT_ABI_WITH_BOOL_OPTION_ERROR_ON_UNREACHABLE_BLOCKS
etc (how long can they be, and is there a cost? can they include lower
case?)

Dave