gdb behaviour change under software watchpoints?

gdb behaviour change under software watchpoints?

[K via Gdb]

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.

Re: gdb behaviour change under software watchpoints?

[Luis Machado via Gdb]

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?

Re: gdb behaviour change under software watchpoints?

[K via Gdb]

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

Re: gdb behaviour change under software watchpoints?

[Luis Machado via Gdb]

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

Re: gdb behaviour change under software watchpoints?

[K via Gdb]

To be clear, I'm not reporting my own bug!
I'm pointing out some inconsistent behaviour of gdb and asking whether
it is a feature of software watchpoints or indeed watchpoint use in general.

On Thu, 24 Apr 2025 at 18:54, K <cq.personal@gmail.com> 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.
>
>
>