Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz <drow at false dot org>]

Thanks for responding!

On Mon, Jul 31, 2006 at 11:32:51PM +0200, Mark Kettenis wrote:
> It all depends on what the external library is used for.  Making
> readline optional wouldn't make much sense, since it is used for GDB's
> primary user interface.  Making expat optional make much more sense to
> me, as I can't see why I'd need it for a native debugger.

I've tried to explain this a couple of times, but I've been a bit
oblique about it.  Here's a clearer attempt, I hope.

The XML descriptions that I'm using for remote targets also encapsulate
information that is useful natively.  They could replace some chunks of
C code in the gdbarch vector, like the bits which adjust NUM_REGS based
on whether SSE/Altivec/FooExt are present, with simpler and more
uniform mechanisms.  And e.g. gdbarch_register_name would also be
covered by the textual description.

For you or me, that's not a particularly big deal.  We know where all
the bits go in existing ports.  But this sort of thing makes it easier
to retarget GDB for custom use, for people who are less familiar with
GDB.

That's not a business concern speaking, if you're wondering - purely
FSF hat.  It's not particularly in CodeSourcery's interest to make GDB
easier to port for people not familiar with it, but I still think it's
a Good Idea.  I get the feeling from your "good of the few" comments
that you're sometimes suspicious of our goals, which I think is really
unfortunate.  Whenever I'm working on the FSF gdb, rather than our
various local branches, I try to keep the goals of the FSF gdb project
in front of me.

And I think the consistency would be really nice, too - delete a few
of the internal interfaces and bundle them up into a clearer and
better documented approach.

And there's automated validation and such that you can do on data files
that isn't possible on C (or is much harder).

I used to think that most of the data-driven approach that I'm
advocating here was basically worthless, but I've been forcibly exposed
to modern software development a couple of times recently, and it
really is a nicer way to work in a lot of ways.

> That said, I'm willing to give in under two conditions:
> 
> 1. We add the necessary glue to the toplevel configure such that it
>    accepts a --with-expat-dir option similar to the --with-gmp-dir
>    option that's already there for GCC.  This will make it possible to
>    keep building everything in one tree, which would come close to
>    removing the objections I raised earlier about problemms installing
>    expat on systems I use to test GDB on.

Did you know that the --with-gmp-dir option doesn't build anything
automatically?  It has to be already built before you can configure
GCC; it does test -f in the specified directory and uses AC_TRY_LINK.

Here's how you'd build them separately with the patch I posted:

  ../expat/configure --prefix=/home/me/gdb-install
  make
  make install

  <elsewhere>

  ../gdb/configure --prefix=/home/me/gdb-install
  make # Will successfully find expat

If that's what you'd like for expat also, I can implement it, but
it's somewhat less useful than what I think you were describing.

Unfortunately you can't take an expat tarball and drop it into the src
tree and have it just build, which is another option.  That requires
a patch, since expat's makefiles do something fairly silly with
CFLAGS that would be a GNU Coding Standards violation if it were
a GNU project :-(

> 2. Try to keep the bits that need expat "optional", and review whether
>    the code that needs it really benefits all of us, or only a few.

I'll leave this at: I think that the bits we are submitting here are
for the benefit of a bigger slice of GDB's users than you do.  See
Sascha's message on gdb@ this weekend for one example.  And I hope it
will eventually be useful for native users of GDB, at least by making
it easier for us (the maintainers) to add support for new hardware
features that they want to debug.

The XML code has both architecture and target components.  While the
only target to implement it is remote.c, it's easy to keep it optional,
and I'm willing.  But I've already got patches which use this for the
sim/ simulators and for native arm-linux debugging, and I have requests
sitting in my queue to do similar things for two native PowerPC
variants (74xx and e500; and at least the 74xx is a popular native
architecture).

-- 
Daniel Jacobowitz
CodeSourcery