This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Fwd: disabling NMI rendering breakpoints non-functional?
- From: Pedro Alves <palves at redhat dot com>
- To: Kent Tong <kent dot tong dot mo at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Wed, 17 Apr 2013 10:36:08 +0100
- Subject: Re: Fwd: disabling NMI rendering breakpoints non-functional?
- References: <CAKs98dH7TShpfKe4cctTfbonDOkbS1m5rVZv0_WiXwqhTsW8ug at mail dot gmail dot com> <CAKs98dFpYNg-Yc8YLHxZ+HV6NBHNm6FkSWR-QbOWLhRHmebkjQ at mail dot gmail dot com> <516C10D3 dot 3020304 at redhat dot com> <CAKs98dFVhz369xBuiycm3rwVYmXED7EtJGckcAYKNcua7+KiNQ at mail dot gmail dot com>
On 04/16/2013 03:09 AM, Kent Tong wrote:
>> GDB has no clue of NMI, it just tells the target to set a breakpoint at
>> some address, or to single-step. How qemu implements those things
>> behind the scenes is up to qemu.
>
> Thanks for the reply! I also figured that. But does the breakpoint if it is
> set to a memory address whose content will be overwritten (e.g., loading
> instructions into there)? In the past it worked, but now somehow it has
> stopped working.
Depends on how qemu implements breakpoints. By default, if the target
doesn't support z0 remote protocol packets, then GDB fallsback to implementing
breakpoints by planting architecture-defined breakpoint instructions (on x86
that's trap3/0xcc), and then handling the resulting trap. Naturally it
won't work if the instruction is overwritten. The emulator is free to
implement the z0/Z0 packets to handle setting breakpoints itself as it
sees fit. It could still be by planting 0xcc instructions or by watching
the address that is about to be executed, or through whatever other means
it comes up with to make that scenario work. GDB doesn't care.
--
Pedro Alves