This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] compile: Use libcc1.so->libcc1.so.0
- From: Pedro Alves <palves at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 23 Apr 2015 12:24:09 +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> <55380F04 dot 9050909 at redhat dot com> <20150423052909 dot GA18986 at host1 dot jankratochvil dot net> <5538CF08 dot 60801 at redhat dot com>
On 04/23/2015 11:52 AM, 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! ;)
> In principle the decision bump is OK; but, and this is the huge
> caveat, we could fix this quite easily by adding another method to the
> vtable exported by the plug-in and not need or require all of the
> tinkering that would be needed downstream. Yes, Fedora could be
> modified to cope with it, but we have to think about the work all the
> other distributions would also have to do if this proposed change were
Not just distributions, but ourselves too. I was much looking forward
to having this feature just work using the system compiler, there's lots
of itches that can be scratched on the gdb side alone. But for people
to first find the itch, they need to be hooked into playing with the
feature first. Permanently keeping the bar high (having to build
gcc trunk) puts people off.
Also, considering an --enable-targets=all build, I'd rather that
gdb was reasonably able to cope with different versions of gcc.
E.g., one might have the most recent version for x86 gcc around, but
not for ARM, etc.
> 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'm not adverse to version changes but I think they should merit the
> change. Possibly as a collection of changes.