Bug 12956 - Watchpoint on invalid memory addressed is too slow, they should be 'pending' until allocated
Summary: Watchpoint on invalid memory addressed is too slow, they should be 'pending' ...
Status: RESOLVED DUPLICATE of bug 10645
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.2
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-02 20:40 UTC by yuri
Modified: 2011-07-31 19:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yuri 2011-07-02 20:40:37 UTC
I am setting a watchpoint for the memory address that is not yet allocated. I am interested in what happens when it is allocated and later.

'watch' statement sets a software watchpoint, and program instantly becomes very slow. My guess is that gdb traces the program and checks if the memory is valid after each instruction. This is wrong.

Since memory can only become valid after mmap or brk/sbrk calls, gdb should only trace those calls in such situation, which is a 'pending' state for a watchpoint. Once the memory address becomes valid, gdb should change status to hardware watchpoint. If the memory is deallocated again (with munmap or brk/sbrk calls) gdb should change state back to 'pending' and wait for the possible other allocations.
Comment 1 Yao Qi 2011-07-06 01:29:22 UTC
(In reply to comment #0)
> I am setting a watchpoint for the memory address that is not yet allocated. I
> am interested in what happens when it is allocated and later.
> 
> 'watch' statement sets a software watchpoint, and program instantly becomes
> very slow. My guess is that gdb traces the program and checks if the memory is
> valid after each instruction. This is wrong.
> 

yes, in software watchpoint, gdb will execute program in a single step manner, and check memory changed or not.  That is why program is slow, but I don't think it is wrong.

> Since memory can only become valid after mmap or brk/sbrk calls, gdb should
> only trace those calls in such situation, which is a 'pending' state for a
> watchpoint. Once the memory address becomes valid, gdb should change status to
> hardware watchpoint. If the memory is deallocated again (with munmap or
  ^^^^^^^^^^^^^^^^^^^
I guess you mean "software watchpoint" here.

> brk/sbrk calls) gdb should change state back to 'pending' and wait for the
> possible other allocations.

This approach you proposed should speed up watchpoint in some cases.  GDB also supports debugging ELF without OS on some bare-mental boards, so syscall mmap/brk/sbrk/ is not available there.
Comment 2 yuri 2011-07-06 01:37:32 UTC
> > watchpoint. Once the memory address becomes valid, gdb should change status to
> > hardware watchpoint. If the memory is deallocated again (with munmap or
>   ^^^^^^^^^^^^^^^^^^^
> I guess you mean "software watchpoint" here.

No I meant hardware watchpoint. If requested memory address isn't available, watchpoint is creates as "Pending". When it becomes available it becomes hardware watchpoint.

On the platforms where mmap/brk/sbrk aren't available previous behavior should be preserved.
Comment 3 Paul Pluzhnikov 2011-07-31 19:08:32 UTC
Exact dup of PR10645

*** This bug has been marked as a duplicate of bug 10645 ***