This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Implementing a remote stub, some questions.
- From: "J.W. Jagersma" <jwjagersma at gmail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 21 Mar 2017 01:54:50 +0100
- Subject: Implementing a remote stub, some questions.
- Authentication-results: sourceware.org; auth=none
Hi,
I am implementing a remote stub for gdb (x86) and I have two questions.
First, the documentation for the 'swbreak' stop reply mentions:
>On some architectures, such as x86, at the architecture level, when a breakpoint instruction executes the program counter points at the breakpoint address plus an offset. On such targets, the stub is responsible for adjusting the PC to point back at the breakpoint address.
Is this only for the INT 3 instruction, or does it apply to INT 1
(trap flag) as well? The latter seems rather complicated to implement.
Second, I want to avoid gdb from tracing into some functions (eg.
non-reentrant memory allocation functions that the stub may use
itself). So for these functions, I clear the trap flag on entry and
restore it on exit. But GDB doesn't like these tricks and immediately
quits with the following message:
```
../../gdb/infrun.c:2751: internal-error: void resume(gdb_signal):
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
```
Is there any way to make this work?