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] |
On 05/20/2013 05:46 PM, David Taylor wrote:
Luis Machado <lgustavo@codesourcery.com> wrote:This is expected since you can actually have two inferiors, but you are only allowed to connect to a single remote target at one time. What would've worked is first connecting to a remote target in *extended* remote mode. Then you would be able to attach to more than a process at a time, or start more than a process at a time. By using "target remote", you're really trying to debug an already active process running on a remote system. I'd suggest reading about the extended remote mode. That looks like what you want, though multiprocess support is still a WIP.Actually, no. The issue is not extended-remote vs remote. We have boxes with multiple boards each running a kernel. The box I tried running gdb against on Thursday has 10 boards of interest. Each running its own instance of the kernel -- 2 instances each of 5 different versions of the kernel.
Ok. It just seemed like the example you used was incorrectly assuming "target remote" would be able to do what "target extended-remote" does.
For that machine if I want to talk to all 10 boards, then I need 10 different tcp connections -- each talking to a different gdb stub.
In the current scenario you would probably need a specialized debugging stub that would be able to multiplex between all of those boards. I've worked with a similar system before.
As for making GDB accept all those different connections at the same time, i don't think it is currently prepared for that.
Luis
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |