This is the mail archive of the gdb@sources.redhat.com 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: gdb for multiprocessor architectures


Hi,

Regarding gdb for multiprocessor architectures, the information required
would be (in a very broad sense, the entire context of a debuggee in gdb,
this starts from the bfd and goes upto the gdbarch implementation for the
same.  ) the bfd, the frame information  , gdbarch information per thread
of execution .

However this would mean replacing a whole load of globals using which gdb
currently operates with corresponding data structures. That is pretty
heavy work . Amits suggestion regarding having a multiplexer is a good
enough short term solution but in terms of maintaining gdb IMHO this
change is happening but over a much different timescale.

But it is happening :-)


GDB currently does horrible overlaying of threads and frame global variables and that is in turn why it keeps ending up with weird and wonderful bugs (per the recent bug report where "info threads" changes the selected frame).

Can there be a single GDB "target vector" that juggles the N JTAG interfaces, presenting to GDB a single "target" with N threads? If that is done the problem is reduced to better structuring thread/frame/arch. and can possibly even be focued down to frame/arch?

Andrew

If you have a single JTAG to communicate with your box then the easiest
thing currently would be to have n sessions of gdb communicating to a
library that takes care of the jtag communications. one for each target !



cheers
Ramana


---- Ramana Radhakrishnan GNU Tools Codito Technologies(Pune) -----




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