public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC 2/7] Add unit test to builtin tdesc generated by xml
Date: Wed, 17 May 2017 09:09:00 -0000	[thread overview]
Message-ID: <20170517110952.0b1fbd10@ThinkPad> (raw)
In-Reply-To: <86a86cajp8.fsf@gmail.com>

Hi Yao,

On Tue, 16 May 2017 16:46:11 +0100
Yao Qi <qiyaoltc@gmail.com> wrote:

> Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
> 
> Hi Philipp,
> Thanks for your comments.
> 
> > The only thing you could have done to make it better is to get rid of the
> > conversion to C altogether and create the target description directly by
> > parsing the XML file. I don't see a benefit in the conversion and removing
> > it would simplify the code even more.  But that is a long term goal and
> > your patch set definitely helps towards that goal.
> 
> As I described in the commit log, "the reason that we transform xml files
> to c files is that GDB is still able to have some target description
> without xml parsing support." so that XML parsing is not a hard
> requirement for GDB.  Nowadays, XML parsing is only used for remote
> debugging.  In native debugging, GDB just uses these pre-generated
> builtin target descriptions, without parsing any XML.

Ok, I see my mistake now.  I thought XML parsing would always be present.
Then the target descriptions could be handled similar to syscalls.  But
that was clearly focused too much on GDB on Linux.  For other systems and
GDBserver this needn't necessarily work...

Sorry for the mistake.
 
> Suppose XML parsing is always there, at least on Linux host, GDB can
> create a big buffer contains various target features in the runtime.  We
> can do this on top of patch 6/7, like this, (take i386-linux as an
> example),
> 
> /* Return a string having XML contents reflecting the right target
>    description according to XCR0.  */
> 
> std::string
> i386_linux_read_description (uint64_t xcr0)
> {
>    std::string buffer;
> 
>    buffer.append ("<?xml version="1.0"?>");
>    buffer.append ("<!DOCTYPE target SYSTEM "gdb-target.dtd">");
>    buffer.append ("<target>");
>    buffer.append ("  <architecture>i386</architecture>");
>    buffer.append ("  <osabi>GNU/Linux</osabi>");
> 
>    if (xcr0 & X86_XSTATE_X87)
>      {
>         /* Open 32bit-core.xml and copy its content here.  */
>      }
> 
>    if (xcr0 & X86_XSTATE_SSE)
>      {
>        /* Open 32bit-sse.xml and copy its content here.  */
>      }
> 
>     ....
> 
>    buffer.append ("</target>");
> 
>    return buffer;
> }
> 
> Even further, this code can be shared between GDB and GDBserver, so that
> GDBserver can compose the XML contents and send it to GDB.  Note that
> GDBserver doesn't need to parse the XML.

That would be neat!

Thanks
Philipp

  reply	other threads:[~2017-05-17  9:09 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 15:55 [RFC 0/7] Make GDB builtin target descriptions more flexible Yao Qi
2017-05-11 15:55 ` [RFC 3/7] Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml Yao Qi
2017-05-11 15:55 ` [RFC 2/7] Add unit test to builtin tdesc generated by xml Yao Qi
2017-05-16 12:00   ` Philipp Rudo
2017-05-16 15:46     ` Yao Qi
2017-05-17  9:09       ` Philipp Rudo [this message]
2017-05-17 16:06     ` Pedro Alves
2017-05-30  8:00       ` Philipp Rudo
2017-06-01 17:53         ` Philipp Rudo
2017-05-17 15:41   ` Pedro Alves
2017-05-18  9:54     ` Yao Qi
2017-05-18 11:34       ` Pedro Alves
2017-05-19 15:47         ` Yao Qi
2017-05-22  8:51           ` Yao Qi
2017-05-11 15:55 ` [RFC 1/7] Move initialize_tdesc_mips* calls from mips-linux-nat.c to mips-linux-tdep.c Yao Qi
2017-05-11 15:55 ` [RFC 7/7] Remove builtin tdesc_i386_*_linux Yao Qi
2017-05-16 12:02   ` Philipp Rudo
2017-05-17 15:46   ` Pedro Alves
2017-05-11 15:55 ` [RFC 5/7] Centralize i386 linux target descriptions Yao Qi
2017-05-11 15:55 ` [RFC 6/7] Lazily and dynamically create i386-linux " Yao Qi
2017-05-11 18:14   ` John Baldwin
2017-05-11 21:03     ` Yao Qi
2017-05-17 15:43   ` Pedro Alves
2017-05-18 15:12     ` Yao Qi
2017-05-19 10:15       ` Pedro Alves
2017-05-19 14:27         ` Yao Qi
2017-05-11 16:06 ` [RFC 0/7] Make GDB builtin target descriptions more flexible Eli Zaretskii
2017-05-11 20:56   ` Yao Qi
2017-05-11 20:55 ` [RFC 4/7] Share code in initialize_tdesc_ functions Yao Qi
2017-05-16 12:02   ` Philipp Rudo
2017-05-17 15:43     ` Pedro Alves
2017-05-18 11:21       ` Yao Qi

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=20170517110952.0b1fbd10@ThinkPad \
    --to=prudo@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).