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] |
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