Re: [PATCH] compile: Use libcc1.so->libcc1.so.0

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Thu, 23 Apr 2015 12:52:56 +0200, Phil Muldoon wrote:
> On 23/04/15 06:29, Jan Kratochvil wrote:
> >
> > So you request forward/backward compatibilities, specifically:
> >
> > (1) Do you request future gdb-7.10 is compatible with existing gcc-5.x?
> >
> > (2) Do you request future gcc-6.0  is compatible with existing gdb-7.9?
> >
> > With an answer for (1) and (2) we can decide on how to implement it.
> 
> Both! ;)

While (1) could be possibly useful personally I do not find
the compatibility (2) useful.


> I don't think a version change merits that. And the change is tiny:
> just one more parameter for a function. You could avoid it by having
> two public methods exported in the vtable: foo (old params), foo (old
> params, new params) and then re-factoring out the old function to
> foo_worker_1 and have the two "foo" functions call foo_worker_1 with
> the new parameter or NULL in its place.

I do not see so clear how to implement it.

If GDB changes:
gdb/compile/compile-c-support.c:110: context = (*func) (GCC_FE_VERSION_0, GCC_C_FE_VERSION_0);
->
gdb/compile/compile-c-support.c:110: context = (*func) (GCC_FE_VERSION_1, GCC_C_FE_VERSION_0);
then compatibiity (1) is violated.  Besides that you said no new API version
should be introduced.

If GCC returns larger vtable for:
gdb/compile/compile-c-support.c:110: context = (*func) (GCC_FE_VERSION_0, GCC_C_FE_VERSION_0);
then GDB has no way to figure out there is the new field at the end of vtable.
Maybe GCC could return in such case 'gcc_base_vtable vtable' with
GCC_FE_VERSION_1 which would be compatible with existing GDBs but I find that
a hack, if GDB asked for GCC_FE_VERSION_0 then it should get
version==GCC_FE_VERSION_0.  Besides that you said no new API version should be
introduced.


Existing implementations only compare 'version' for equality.  IMO for your
requested compatibility (1)+(2) it would be most clean to have an additional
field 'minor_version' which would be compared for less-or-equal (by GCC as
a minimal functionality level requested by GDB and by GDB as a functionality
level supported by GCC).  This was omitted by the initial interface design.


> What are your thoughts?

I think that trunk versions of API should not be complicated by backward
compatibility when we control trunk versions of both client and server.


I can implement the variant I marked as "hack" above which satisfies both
compatibilities (1) and (2).


Jan