On Fri, Oct 17, 2008 at 12:18 PM, Duane Ellis <[EMAIL PROTECTED]> wrote: > Øyvind Harboe wrote: >> >> Currently each target gets it's own GDB server. >> >> However, I'm thinking that it would be better in most cases to >> have each CPU represented as a thread in GDB. That way only >> one debug session needs to be opened. >> >> This would be for CPUs of the same type that share memory. >> >> Thoughts? >> > > 1) What if I have two different ARCH, like ARM7tdmi + ARM-Cortex? Or worse > - ARM + DSP on the same target?
That I think two GDB servers are more approperiate. > 2) What if GDB already knows about my threads? OpenOCD does not currently have any threads support. If it grows threads support, i don't see that as a conflict with representing each CPU as thread. > > 3) GDB assumes a single address space for all threads - *MAYBE* true for > *SOME* multi-core cpu. But - not all multi-cores have common address space. > ie: Blackfin BF561 - has 2 cores, shares external SDRAM but - each core has > its own private on chip SRAM that is not accessible by the other core, also > the two cores are non-cache coherent. At some point it's better to break it apart to multiple GDB servers, but for the simplest SMP shared memory model case, I'd prefer a single gdb server w/multiple threads. > > > -Duane. > > > > -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer Free eCos workshop in Oslo October 21! http://www.zylin.com/workshop.html _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
