gdb for multiprocessor architectures
Andrew Cagney
cagney@gnu.org
Wed Dec 31 17:53:00 GMT 2003
> 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)
> -----
>
More information about the Gdb
mailing list