SIGINT signal sent to GDB 7.12 process does not stop target

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SIGINT signal sent to GDB 7.12 process does not stop target

Alexandru-Adrian Oltean
Hi everyone,

After upgrading to GDB 7.12 (from GDB 7.11), I noticed some weird behavior when comes to sending SIGINT to the GDB process. This happens only on Linux hosts. Long story short is that after sending SIGINT to GDB, I see "^CQuit" being printed in console but target doesn't get stopped. I'm dealing with an ARMv8 target and the problem I'm seeing happens only when the GDB is started via some python scripts and using pexpect module to interact with GDB.

Very briefly, I have a setup like this:

  *   I'm using some python scripts that start GDB (pexpect.spawn)
  *   Via those scripts, GDB connects to the target, configures it, loads the elf file and then resumes the target; all these steps are performed using pexpect module from python
  *   Send SIGINT to GDB process right from the python scripts (e.g. my_gdb_process.kill(2))
At this point, I see "^CQuit" in the GDB's console but target not being stopped. GDB also gives the prompt back and I'm able to send other commands. Note that this behavior is seen only when interacting with GDB using pexpect and python scripts. Interesting enough is that CTRL+C suspends target when I manually start GDB and input all those commands.

On a side-note, I also noticed that Eclipse (Oxygen.0 in my case) can't stop the target either. I see the same "^CQuit" message in the new "Debugger Console". This happens only on Linux hosts. As far as I understood after reading some mailing lists, Eclipse has the issue fixed in some new GDB Hardware Debugging plugin release but I did not have the chance to verify this.

Any ideas why am I seeing that weird behavior only when using python/pexpect? Looking in the GDB 7.12 release announcement, I don't see anything that could be related what I'm experimenting.

Thanks,
Adrian


Reply | Threaded
Open this post in threaded view
|

答复: SIGINT signal sent to GDB 7.12 process does not stop target

高国胜
Dear all!
What's the status about this issue?

-----邮件原件-----
发件人: [hidden email] [mailto:[hidden email]] 代表 Adrian Oltean
发送时间: 2017年10月19日 15:32
收件人: '[hidden email]'
主题: SIGINT signal sent to GDB 7.12 process does not stop target

Hi everyone,

After upgrading to GDB 7.12 (from GDB 7.11), I noticed some weird behavior when comes to sending SIGINT to the GDB process. This happens only on Linux hosts. Long story short is that after sending SIGINT to GDB, I see "^CQuit" being printed in console but target doesn't get stopped. I'm dealing with an ARMv8 target and the problem I'm seeing happens only when the GDB is started via some python scripts and using pexpect module to interact with GDB.

Very briefly, I have a setup like this:

  *   I'm using some python scripts that start GDB (pexpect.spawn)
  *   Via those scripts, GDB connects to the target, configures it, loads the elf file and then resumes the target; all these steps are performed using pexpect module from python
  *   Send SIGINT to GDB process right from the python scripts (e.g. my_gdb_process.kill(2))
At this point, I see "^CQuit" in the GDB's console but target not being stopped. GDB also gives the prompt back and I'm able to send other commands. Note that this behavior is seen only when interacting with GDB using pexpect and python scripts. Interesting enough is that CTRL+C suspends target when I manually start GDB and input all those commands.

On a side-note, I also noticed that Eclipse (Oxygen.0 in my case) can't stop the target either. I see the same "^CQuit" message in the new "Debugger Console". This happens only on Linux hosts. As far as I understood after reading some mailing lists, Eclipse has the issue fixed in some new GDB Hardware Debugging plugin release but I did not have the chance to verify this.

Any ideas why am I seeing that weird behavior only when using python/pexpect? Looking in the GDB 7.12 release announcement, I don't see anything that could be related what I'm experimenting.

Thanks,
Adrian



------Please consider the environment before printing this e-mail.