Re: gdb behaviour change under software watchpoints?

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.

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
```


On Fri, 25 Apr 2025 at 15:09, Luis Machado <[email protected]> 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?
>