From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Tristan Gingold <gingold@adacore.com>,
"gdb-patches@sourceware.org ml"
<gdb-patches@sourceware.org>
Subject: Re: RFA: Try to include libunwind-ia64.h in libunwind-frame.h
Date: Tue, 14 Feb 2012 14:53:00 -0000 [thread overview]
Message-ID: <4F3A7531.6050303@redhat.com> (raw)
In-Reply-To: <20120214143545.GA22678@host2.jankratochvil.net>
On 02/14/2012 02:35 PM, Jan Kratochvil wrote:
> At least `libunwind_frame_unwind' is dead - it has no references in the
> codebase - which confused me.
It's dead for IA-64 as well. It's likely dead for any other arch that may
want to use libunwind. So "if the non-ia64 libunwind support is therefore
really removed the dead code in libunwind-frame.c should be also removed"
is not the right justification to remove the dead code. If you want to
remove it, go ahead, but do it because it's dead, period.
> Also when you change GDB design by this patch - from arch-independent
> libunwind-frame.c to ia64-limited libunwind-frame.c - one should best rename
> libunwind-frame.[ch] to libunwind-ia64-frame.[ch]. Otherwise at least write
> some comments there this file is used only for ia64 targets now.
I have already added such comments to libunwind-frame.h. The limitation that
the file is only usable by ia-64 is pre-existing. I'm not adding anything
new, other than making the limitation _explicit_, which is a good thing.
I'm adding this comment to libunwind-frame.c
/* IA-64 is the only target that currently uses libunwind-frame. Note
how UNW_TARGET, UNW_OBJ, etc. are compile time constants below.
Those come from libunwind's headers, and are target dependent.
Also, some of libunwind's typedefs are target dependent, as e.g.,
unw_word_t. If some other target wants to use this, we will need
to do some abstracting in order to make it possible to select which
libunwind we're talking to at runtime (and have one per arch). */
Are you fine with that?
>> > The code is not really ia64 specific.
> Yes, because it was designed to be possibly used in the future with arbirary
> arch.
I don't understand what are we discussing. The possibility is there, but it
needs work to get there. When the future comes, we'll have to adjust. Right
now, nobody but IA-64 cares. Making the limitation explicit by including
the ia64 header directly doesn't make the needed work more difficult one
single bit. On the contrary.
--
Pedro Alves
next prev parent reply other threads:[~2012-02-14 14:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 16:32 Tristan Gingold
2012-02-10 12:31 ` Jan Kratochvil
2012-02-10 13:15 ` Tristan Gingold
2012-02-10 13:21 ` Jan Kratochvil
2012-02-10 13:27 ` Joel Brobecker
2012-02-10 13:45 ` Tristan Gingold
2012-02-10 14:04 ` Tristan Gingold
2012-02-10 14:09 ` Jan Kratochvil
2012-02-10 14:14 ` Tristan Gingold
2012-02-10 18:27 ` Jan Kratochvil
2012-02-10 18:34 ` Pedro Alves
2012-02-10 18:44 ` Jan Kratochvil
2012-02-10 18:59 ` Pedro Alves
2012-02-10 19:38 ` Jan Kratochvil
2012-02-11 14:10 ` Jan Kratochvil
2012-02-13 8:41 ` Tristan Gingold
2012-02-13 18:58 ` Pedro Alves
2012-02-13 19:03 ` Jan Kratochvil
2012-02-13 19:20 ` Pedro Alves
2012-02-13 19:27 ` Jan Kratochvil
2012-02-13 20:05 ` Pedro Alves
2012-02-14 7:28 ` Jan Kratochvil
2012-02-14 12:14 ` Pedro Alves
2012-02-14 14:36 ` Jan Kratochvil
2012-02-14 14:53 ` Pedro Alves [this message]
2012-02-20 20:54 ` Jan Kratochvil
2012-02-20 22:30 ` Pedro Alves
2012-02-20 22:37 ` Joel Brobecker
2012-02-20 22:39 ` Joel Brobecker
2012-02-20 22:57 ` Pedro Alves
2012-02-20 23:20 ` Joel Brobecker
2012-02-21 6:48 ` Jan Kratochvil
2012-02-21 13:36 ` Pedro Alves
2012-02-21 19:10 ` Tom Tromey
2012-02-22 7:56 ` Tristan Gingold
2012-02-22 14:52 ` Jan Kratochvil
2012-02-21 20:18 ` Jan Kratochvil
2012-02-21 20:43 ` Pedro Alves
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=4F3A7531.6050303@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=gingold@adacore.com \
--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