This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] Pre-parse XML target descriptions


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]