This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] compile: Use libcc1.so->libcc1.so.0
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 23 Apr 2015 13:47:45 +0200
- Subject: Re: [PATCH] compile: Use libcc1.so->libcc1.so.0
- Authentication-results: sourceware.org; auth=none
- References: <20150421213616 dot 14023 dot 38329 dot stgit at host1 dot jankratochvil dot net> <55380F04 dot 9050909 at redhat dot com> <20150423052909 dot GA18986 at host1 dot jankratochvil dot net> <5538CF08 dot 60801 at redhat dot 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