Re: errors in GDB reading symbols

[Tom Tromey <tromey@redhat.com>]

Marco> Partially the earlier own debugger discussion is fueled by one of
Marco> the improvements of FPC's internal linker relative to LD, the
Marco> experience that makes the call for an own debugger so vocal. It
Marco> knocks off tens of seconds in the compile-start-with-debug cycle,
Marco> and makes GDB the next bottleneck (this is for Lazarus, not the
Marco> textmode IDE)

FWIW, I'm definitely interested in speed problems in GDB.  If you find
them, and can characterize them nicely, please file bug reports.

Marco> Forcing the MI interface would effectively kill the textmode IDE, it is
Marco> effectively in maintenance for years. If there is something to be done on
Marco> the GDB side, I'd prefer investing time in libgdb. What are the problems
Marco> with it? Does something need updating, etc?

I think that historically libgdb is just an idea that never really got
beyond the "put a lot of .o files into libgdb.a" stage.

When I look at GDB, I think there are a few things that make it a less
than great library:

* No use of namespaces for functions and globals
* ABI changes every release
* Unfriendly "embedding" behavior: takes over signals, requires
  application discipline about calling wait(), etc.

I guess those are the big ones.  If they don't bother you, cool.

Marco> I don't see the point of the MI interface at all btw. What is the idea
Marco> behind it? And why does it need to be one size fits all to desperately?

I'm not really aware of the full history of MI, but one big advantage is
that lots of people use it and it is supported.

I suppose the basic idea is that a text-based protocol is more
future-proof than a binary ABI.  (Of course this is not intrinsically
true, but it is made true because I don't think that restricting GDB to
be ABI-compatible is reasonable.)

I have two reasons I would want to remove libgdb.  First, I think that
supporting gdb-as-a-library is too much work for not enough payoff.
(Though this reason is somewhat deflated if you don't mind the "anything
goes" approach.)  Second, libgdb.a slows down the build, which is
pointless for something we don't support.

Tom