Hi All,
We are using GDB 7.5 (via MI protocol) to debug a remote multi-core target in non-stop mode. We use custom GDB Server and GDB thread packets are interpreted as hardware core for multi-core debugging. Everything is working fine except that step over through a piece of code which is simultaneously accessed by both cores is failing. The failing scenario can be explained as below: 1. Core 0 is halted and core 1 is running before single stepping 2. When user single step core 0, GDB puts a BP in next location and run the target 3. Since core 1 is also executing this piece of code, core 1 takes this BP (GDB expect core 0 to take BP) 4. Our custom GDB Server sends the stop notification packet of core 1 5. Irrespective of the fact that notification packet of core 1 was send, GDB tries to read register/memory values of core0 (which is running) 6. GDB Server respond with error packet and GDB stops functioning Packets exchanged between GDB and GDB Server for single step : Sending packet: $m80009000,4#5e...Ack Packet received: 0800e003 Sending packet: $m80009000,4#5e...Ack Packet received: 0800e003 Sending packet: $qTStatus#49...Ack Packet received: Sending packet: $m80009000,4#5e...Ack Packet received: 0800e003 Sending packet: $m80009000,4#5e...Ack Packet received: 0800e003 Sending packet: $Z0,8000b024,4#d6...Ack Packet received: OK Packet Z0 (software-breakpoint) is supported Sending packet: $vCont;c:1#13...Ack //GDB run core 1 Packet received: OK Notification received: Stop:T05thread:02; //Core 2 is halted stop notification captured Sending packet: $vStopped#55...Ack Packet received: OK Sending packet: $Hg2#e1...Ack Packet received: OK Sending packet: $g#67...Ack Packet received: 00000000008b0010e08f0080020000000800c7cf424cfb231a0000001a00000000000000 000000001a000000000062cfb81962cfa412b97f00ca9a3b00004800020000006476bc80 0000bc80accdbb800000bc808722c73b4337c3336322cf1f00000000d0300577081fc7cf 081fc7cf0000c7cf081fc7cf032387bd24b00080018b00107cf82198d64f000094c40e77 0000800024b00080 Sending packet: $Hg1#e0...Ack //Though Core 2 was halted, GDB is requesting for Core 1 details Packet received: E 00 Sending packet: $g#67...Ack Packet received: 00000000008b0010e08f0080020000000800c7cf424cfb231a0000001a00000000000000 000000001a000000000062cfb81962cfa412b97f00ca9a3b00004800020000006476bc80 0000bc80accdbb800000bc808722c73b4337c3336322cf1f00000000d0300577081fc7cf 081fc7cf0000c7cf081fc7cf032387bd24b00080018b00107cf82198d64f000094c40e77 0000800024b00080 Target is executing. Is there a way to overcome this limitation? Is there any commands in GDB to handle such scenarios? Or is there any GDB patch? Or is it because something is missing in our custom GDB Server? Any hint to help us progress is highly appreciated. Thanking in anticipation, Rejeesh ***** Confidentiality Statement/Disclaimer ***** This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.
