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: Phil Muldoon <pmuldoon at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches at sourceware dot org
- Date: Wed, 22 Apr 2015 22:13:40 +0100
- 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>
On 21/04/15 22:36, Jan Kratochvil wrote:
> Hi,
>
> the next [patch 3/4] will change the libcc1.so API. I am not sure if it gets
> approved in GCC land but for such case:
> (1) We really need to change GCC_FE_VERSION_0 -> GCC_FE_VERSION_1, this
> feature is there for this purpose. That is [patch 2/4].
> (2) Currently GDB does only dlopen("libcc1.so") and then depending on which
> libcc1.so version it would find first it would succeed/fail.
> I guess it is more convenient to do dlopen("libcc1.so.1") instead
> (where ".1"=".x" corresponds to GCC_FE_VERSION_x).
> That is this patch (with x=0).
> (3) Currently there is no backward or forward compatibility although there
> could be one implemented. Personally I think the 'compile' feature is
> still in experimental stage so that it is OK to require last releases.
> At least in Fedora we can keep GDB<->GCC in sync.
>
>
Will this mean that the next release of GDB will require GCC 5.0.1 (or
whatever the next version of GCC after 5.0)?
If so, then, I object. This could mean many months of GDB and GCC
releases not coinciding and no functionality being present. If not,
how does GDB work with an older GCC? It also does not seem a good
thing to change the API before GCC 5.0 is even released.
I think as far as possible we want to be fault tolerant with
GCC. Another solution is to add another method to the end of the
vtable of functions presented to GDB from the GCC plugin, and save API
changes for more synchronized and planned changes.
Cheers
Phil