This is the mail archive of the gdb-patches@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 09/09/2015 12:40 PM, Pedro Alves wrote:
On 09/09/2015 05:08 PM, Sandra Loosemore wrote:On 09/08/2015 10:30 AM, Pedro Alves wrote:Yeah, I've seen this before with a local series I use for debugging software single-step things that implements software single-stepping on x86. I just re-tried it now after rebasing that series to current mainline, and I still see the time outs against gdbserver. AFAICS, nios2 is a software single-step target that does not implement displaced stepping either. I had a patch for this that I had never posted. See attached.Hmmm, these two patches are not working for me. The trouble is that this part:+gdb_test_multiple "si" $msg { + -re "displaced pc to.*$gdb_prompt $" { + set displaced_stepping_enabled 1 + } + -re ".*$gdb_prompt $" { + } +}is causing the target to step from main to pthread_self, which is in a different file. This causes the subsequent breakpoint commands to fail, and things go south from there:OK, I got "lucky" on x86 and a stepi runs some instruction before the call. Could you try simply replacing the "si" with "next" ? It doesn't matter whether that issues several single-steps or not. What matters is that gdb tries to step past the breakpoint that is set at the current PC (from the earlier runto_main). We're trying to figure out if gdb uses displaced stepping for that.
Yes, that fixes the trouble, and the tests run OK now. I did find that it still timed out 1 of the 5 times I ran it, though, so maybe the timeout factor really does need to match NUM_THREADS to be safe?
-Sandra
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |