Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: Re: [rfc] Pre-parse XML target descriptions
Date: Fri, 05 Oct 2007 16:51:00 -0000	[thread overview]
Message-ID: <m3myuxld1y.fsf@codesourcery.com> (raw)
In-Reply-To: <20071005153350.GA23583@caradoc.them.org> (Daniel Jacobowitz's message of "Fri, 5 Oct 2007 11:33:50 -0400")


Daniel Jacobowitz <drow at false.org> writes:
> So far, I've used the target description mechanism I implemented for
> three purposes:
>
>   - Remote targets, where the description is an XML file provided
>   either by the target or by a "set tdesc filename" command.
>
>   - Built-in descriptions, which are constructed manually in C code.
>   For example the registers-are-64-bit MIPS property which we infer
>   from the size of a remote 'g' packet.
>
>   - New native register sets, where the description is an XML file
>   converted to a C string and compiled into GDB.
>
> That last one is a bit unsatisfactory.  It means that if we choose to
> use an XML file to describe a target, then users of that target are
> required to link with expat and will get slightly mysterious warnings
> about disabled XML support if they don't.  I'm trying to make the
> use of data instead of code for these descriptions as attractive as
> possible and this makes it unattractive.  And I have a patch coming
> up which changes an existing target rather than adding a new one.
>
> There's one obvious solution: require expat.  But that's not
> practical, it seems.  So here's an alternative solution: convert the
> XML files to equivalent C fragments and include them in the source
> tree.  It's fairly straightforward to do, and more efficient at
> startup.  You need an XML-supporting GDB for an appropriate target
> that runs on your build machine to generate the C files, so it's not
> practical to generate them automatically during build.

Is this impractical because one must build GDB twice, or because one
can't assume expat is present?

If it's only the latter, then 'maint print c-tdesc' could be compiled
in one of two ways, depending on whether expat is present:

- When expat is present, it generates output as normal.

- When expat is not present, it merely compares a wide checksum of the
  input file with a checksum stored in the output file of the input it
  was generated from, reports success if they match, and prints an
  error message saying "You need to rebuild GDB with expat, because
  you've modified your XML file" if they don't.


  reply	other threads:[~2007-10-05 16:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-05 15:34 Daniel Jacobowitz
2007-10-05 16:51 ` Jim Blandy [this message]
2007-10-05 16:54 ` Jim Blandy
2007-10-05 17:40   ` Daniel Jacobowitz
2007-10-05 17:52     ` Jim Blandy
2007-10-05 17:59       ` Daniel Jacobowitz
2007-10-15 19:26 ` Daniel Jacobowitz

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=m3myuxld1y.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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