This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

Re: GDB: one version for all targets



   Date: Wed, 17 Feb 1999 13:25:21 +1100
   From: Brendan Simon <brendan@dgs.monash.edu.au>

   >From some of the discussions on this list, I have interpretted that GDB may
   be moving to one version that can dynmically detect the CPU target and ABI
   type.  A manual setting for these is provided as a fallback if autodetection
   fails.

   Does this mean there would only be one GDB that would cater for all targets.
   eg. i386, powerpc, m68k, etc ?

Yes, that ought to be possible some day.  It would it to be like a config
option, a la BFD's --with-targets=all.

   This sounds like a fantastic idea and I look forward to such a versatile
   debugger.
   Does anyone know when this is likely to be available ?

It's going to be awhile.  This is more of a direction, not a scheduled
commitment, and availability is going to be depend on how many people
actually work on this.  Can't depend on Cygnus to do it all, since among
other things we don't even have all the targets inhouse to test.

   I assume the correct simulator would be called based on the above settings.

The existing builtin simulators all present the same API, and thus are
not set up to link in more than one.  However, it would be sensible to
build sims into gdbserver and have a single debugger able to talk with
any of the servers.

   To reduce diskspace, would it be possible to have the supported targets and
   ABI types as some kind of shared library or plug in module ?

That would certainly be a good way to implement.  In practice, most
users don't care, because it primarily matters to embedded developers
using multiple architectures at once.  It's going to be a long time
before a single GDB can be both a native x86 Linux and PA HP-UX debugger! :-)

The real value in this sort of change is for things like
multiprocessor cross-debugging, which is an exotic activity nowadays,
but I expect it will become more common in the future.

								Stan