From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Alexander Graf <agraf@suse.de>,
QEMU Developers <qemu-devel@nongnu.org>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
"Vassili Karpov (malc)" <av1474@comtv.ru>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Edgar Iglesias <edgar.iglesias@gmail.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml
Date: Mon, 6 Oct 2014 21:14:33 +0200 [thread overview]
Message-ID: <20141006211433.13e63cf0@thinkpad-w530> (raw)
In-Reply-To: <CAFEAcA977vpP05ENxCmETeiX7UDnTzLmcJ3ikNcN1_5naoVXUw@mail.gmail.com>
> On 6 October 2014 16:08, Cornelia Huck <cornelia.huck@de.ibm.com> wrote:
> > On Tue, 30 Sep 2014 17:23:47 +0200
> > Jens Freimann <jfrei@linux.vnet.ibm.com> wrote:
> >
> >> From: David Hildenbrand <dahi@linux.vnet.ibm.com>
> >>
> >> This patch provides the name of the architecture in the target.xml if available.
> >>
> >> This allows the remote gdb to detect the target architecture on its own - so
> >> there is no need to specify it manually (e.g. if gdb is started without a
> >> binary) using "set arch *arch_name*".
> >>
> >> The name of the architecture has been added to all archs that provide a
> >> target.xml (by supplying a gdb_core_xml_file) and have a unique architecture
> >> name in gdb's feature xml files.
> >>
> >> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
> >> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> >> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >> Signed-off-by: Jens Freimann <jfrei@linux.vnet.ibm.com>
> >> Reviewed-by: Andreas Färber <afaerber@suse.de>
> >> Cc: Andrzej Zaborowski <balrogg@gmail.com>
> >> Cc: Peter Maydell <peter.maydell@linaro.org>
> >> Cc: Vassili Karpov (malc) <av1474@comtv.ru>
> >> CC: Edgar Iglesias <edgar.iglesias@gmail.com>
> >> CC: Richard Henderson <rth@twiddle.net>
> >> ---
> >> gdbstub.c | 19 ++++++++++++-------
> >> include/qom/cpu.h | 2 ++
> >> target-arm/cpu64.c | 1 +
> >> target-ppc/translate_init.c | 2 ++
> >> target-s390x/cpu.c | 1 +
> >> 5 files changed, 18 insertions(+), 7 deletions(-)
> >>
> > I will send this with the next pile of s390x updates, unless someone on
> > cc: has any objections.
>
> I'm still hoping for an answer about why this is setting
> the name for 64 bit ARM and not 32 bit ARM, and whether
> there are any cases which need to actually be able to set
> the architecture name in a more complicated name than
> simply a string. I raised those in the last lot of review
> and there doesn't seem to have been any answer.
>
> thanks
> -- PMM
>
Hi Peter,
actually the questions were addressed in the last review. Haven't received any
answer from you to my reply. Maybe some mails got lost in the system.
32bit arm:
-"On my way through the possible architecture names
(binutils-gdb/gdb/features/*.xml), I wasn't able to come up with the right name
for arm 32 bit (arm-core.xml) - they don't specify any. This patch therefore
adapts to the xml files from gdb."
- Not included in this patch as Edgar provided a patch in the previous thread
(that's why he is on cc) that can easily be adopted. I don't want to simply
include his effort in my patch :) And we have to make sure that this name is
the right one.
More complicated names:
- "The architecture should be known at the same point when specifying the xml
file. So if anyone can come up with the proper arm name in the future (or even some
kind of detection algorithm), it can simply be set in target-arm/cpu.c (after
"arm-core.xml")."
- The same should apply for all architectures. So we can set (or even build)
the proper string when also specifying the core xml file.
Do you have something in mind like your "powerpc:common" and "powerpc:e500"
example? To build the names based on some pattern?
I don't think that we can generalize the name format here (at least "aarch64"
makes me assume that :) ). I think it would be enough to set the complete
strings in the class init functions.
What do you think? Any suggestions?
Thanks!
David
next prev parent reply other threads:[~2014-10-06 19:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 15:23 [Qemu-devel] [PATCH] gdb: detect target architecture via target.xml Jens Freimann
2014-09-30 15:23 ` [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml Jens Freimann
2014-10-06 15:08 ` Cornelia Huck
2014-10-06 16:57 ` Peter Maydell
2014-10-06 19:14 ` David Hildenbrand [this message]
2014-10-06 19:39 ` Peter Maydell
2014-10-06 19:56 ` David Hildenbrand
2014-10-06 17:14 ` Peter Maydell
2014-10-06 19:44 ` David Hildenbrand
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=20141006211433.13e63cf0@thinkpad-w530 \
--to=dahi@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=av1474@comtv.ru \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=edgar.iglesias@gmail.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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;
as well as URLs for NNTP newsgroup(s).