This is the mail archive of the gdb@sourceware.org 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]

Cyclops64 Multi-Process


Dear list,

I have successfully ported gdb 7.1 to Cyclops64 and it is quite stable.
My next task is to implement multi-processor debugging for use in a
super computer. There can be many processors connected through some
interface, each processor having many parallel threads, and all of them
executing the same program.

It would be easy for me to allow gdb to assign a thread id to each
thread on every processor as the stop event arrives. But there can be
100,000+ threads and users tend to think of each thread in terms of the
node that it executes on. Therefore the multiprocess extensions of gdb
seemed like a nice fit because of the 'process.thread' syntax.

The gdb client accepts the stop events for the first pid, but any stop
event thereafter causes the following error: "internal-error: Can't
determine the current address space of thread Thread 2.1"

Do you think shoehorning multiprocess extensions into my multi processor
system is a good idea? Is there something I can manipulate in the
protocol to make the gdb client happy?

Thank you,
Brian


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