[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue using GDB for non-stop multi-core debugging.
From: |
Rejeesh S. Babu |
Subject: |
RE: Issue using GDB for non-stop multi-core debugging. |
Date: |
Thu, 14 Feb 2013 11:27:37 +0530 |
Hi All,
Sorry that I need to keep asking this again as the below issue is seriously
troubling me.
Would appreciate if anyone can patiently read my below query and help me out in
any way....
For those who feel that the below mail is too long to read, I would re-word it
in a single liner:
"GDB stepping fails in SMP multi-core system whenever core switching(0->1 OR
1->0) happens before stepping is completed".
Right now, I am debugging GDB source code to see if I can fix it myself. Any
hints (files to concentrate) in GDB source code debugging is also appreciated.
Expecting prompt response.
Regards,
Rejeesh
-----Original Message-----
From: Rejeesh S. Babu
Sent: Tuesday, December 04, 2012 5:45 PM
To: 'address@hidden'; 'address@hidden'
Subject: Issue using GDB for non-stop multi-core debugging.
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:
00000000008b0010e08f0080020000000800c7cf424cfb231a0000001a00000000000000000000001a000000000062cfb81962cfa412b97f00ca9a3b00004800020000006476bc800000bc80accdbb800000bc808722c73b4337c3336322cf1f00000000d0300577081fc7cf081fc7cf0000c7cf081fc7cf032387bd24b00080018b00107cf82198d64f000094c40e770000800024b00080
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:
00000000008b0010e08f0080020000000800c7cf424cfb231a0000001a00000000000000000000001a000000000062cfb81962cfa412b97f00ca9a3b00004800020000006476bc800000bc80accdbb800000bc808722c73b4337c3336322cf1f00000000d0300577081fc7cf081fc7cf0000c7cf081fc7cf032387bd24b00080018b00107cf82198d64f000094c40e770000800024b00080
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.
- RE: Issue using GDB for non-stop multi-core debugging.,
Rejeesh S. Babu <=