Re: gdb behaviour change under software watchpoints?

[Luis Machado via Gdb <gdb@sourceware.org>]

On 4/25/25 17:04, K via Gdb wrote:
> trying to set a hw watchpoint I get this:
> ```
> (gdb) watch *0x550195e010
> Hardware watchpoint 1: *0x550195e010
> (gdb) c
> Continuing.
> Warning:
> Could not insert hardware watchpoint 1.
> Could not insert hardware breakpoints:
> You may have requested too many hardware breakpoints/watchpoints.

I'm assuming gdb requested things to qemu, but qemu for some reason couldn't honor the request of inserting the hardware watchpoint.

Is that memory location pointing to data or executable instructions?

Does it work if you add a hardware watchpoint to monitor a trivial integer, for instace?

> 
> Command aborted.
> ```
> 
> so I switched to s/w watchpoint:  set can-use-hw-watchpoints 0
> 
> here's the output when I don't use an expression to look for a specific
> value (which didn't show up)
> but self examine the value at an address and just continue on until the
> abort():
> ```
> gdb-multiarch -q -x gdbinit  ../_build/cross/bin/ocamljitlinker
> Reading symbols from ../_build/cross/bin/ocamljitlinker...
> The target architecture is set to "aarch64".
> warning: remote target does not support file transfer, attempting to access
> files from local filesystem.
> 0x0000005504303300 in ?? () from
> /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1
> Watchpoint 1: *0x550195e010
> c
> 
> Watchpoint 1: *0x550195e010
> 
> Old value = <unreadable>
> New value = 0x0
> 0x0000005504519a40 in brk () from /usr/aarch64-linux-gnu/lib/libc.so.6
> (gdb) Continuing.
> 
> Watchpoint 1: *0x550195e010
> 
> Old value = 0x0
> New value = 0x4a20001
> caml_page_table_modify (page=page@entry=0x5504a20000,
> toclear=toclear@entry=0x0,
> toset=toset@entry=0x1) at memory.c:176
> 176      caml_page_table.occupancy++;
> (gdb) c
> Continuing.
> 
> Watchpoint 1: *0x550195e010
> 
> Old value = 0x4a20001
> New value = 0x9100a021
> 0x00000055044d91c4 in ?? () from /usr/aarch64-linux-gnu/lib/libc.so.6
> (gdb) c
> Continuing.
> [Inferior 1 (process 1) exited with code 02]
> ```
> 
> what I see at this point without any watchpoint:
> ```
> Program received signal SIGABRT, Aborted.
> 0x00000055044bf5e8 in ?? () from /usr/aarch64-linux-gnu/lib/libc.so.6
> ```

In some cases gdb has the unfortunate side-effect of (unwillingly) changing the execution flow. But in this case it is not clear why you'd get a SIGABRT elsewhere and exit normally when using watchpoints.

> 
> 
> On Fri, 25 Apr 2025 at 15:09, Luis Machado <luis.machado@arm.com> wrote:
> 
>> On 4/24/25 17:54, K via Gdb wrote:
>>> A bug in my software is revealed by a debug build which eventually calls
>>> abort(). gdb sees and reports this and I can do a backtrace and find a
>>> memory location I need to investigate.
>>> then I make a run with a watchpoint on said memory location which has to
>> be
>>> software since it's a non-host binary running under qemu.
>>> not only does the watchpoint not get triggered despite ensuring binary is
>>> being loaded to the same address, but gdb only reports that the process
>> has
>>> exitted with an error code - no memory to examine, no backtrace.
>>>
>>> the former is mysterious but the latter is annoying - is this behaviour
>>> necessitated by setting watchpoints?
>>> I have remote access to a machine of the target variety but I would ask
>>> first whether I can expect the behaviour to return to normal when using a
>>> hardware watchpoint. No point is going down a dead end...
>>> Thanks.
>>
>> qemu should know how do do hardware breakpoints. Do you have some logging
>> output
>> from when the watchpoint gets set until gdb runs until the program exits?
>>