[Bug gdb/12956] Watchpoint on invalid memory addressed is too slow, they should be 'pending' until allocated

["qiyao at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12956

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qiyao at gcc dot gnu.org

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> 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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.