From: Phil Muldoon <pmuldoon@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] compile: Use libcc1.so->libcc1.so.0
Date: Wed, 22 Apr 2015 21:13:00 -0000 [thread overview]
Message-ID: <55380F04.9050909@redhat.com> (raw)
In-Reply-To: <20150421213616.14023.38329.stgit@host1.jankratochvil.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
next prev parent reply other threads:[~2015-04-22 21:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-21 21:36 Jan Kratochvil
2015-04-21 21:38 ` mail dup cancel: " Jan Kratochvil
2015-04-22 21:13 ` Phil Muldoon [this message]
2015-04-23 5:29 ` Jan Kratochvil
2015-04-23 10:53 ` Phil Muldoon
2015-04-23 11:24 ` Pedro Alves
2015-04-23 11:47 ` Jan Kratochvil
2015-04-23 11:59 ` Pedro Alves
2015-04-23 11:42 ` Pedro Alves
2015-04-23 11:51 ` Jan Kratochvil
2015-04-23 11:52 ` Jan Kratochvil
2015-04-23 12:07 ` Pedro Alves
2015-04-23 12:24 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55380F04.9050909@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox