Re: Setting watchpoints in GDB
Re: Setting watchpoints in GDB
- Subject: Re: Setting watchpoints in GDB
- From: Jim Ingham <email@hidden>
- Date: Mon, 25 Oct 2004 10:31:04 -0700
That's right, single stepping was MUCH worse, especially because the
PPC processor won't single step over the class of instructions that are
used to implement locks, so the program would just hang if it ever
tried to take a lock. The kernel folks don't want to expose the DABR
register (the one used for hardware watchpoints on the PPC) to user
space, so page protection is the best we can do.
The way gdb does watchpoints is sometimes too clever for it's own good,
since it watches all the components of the expression to see if ANY of
them change. SO if you tell it to watch this->that->theOther, it will
watch all three memory locations. That's sometimes very useful, but
can mean you end up watching lots more than you expected. That's why
you might want to resolve the address you want to watch first, then
tell gdb to watch just that location.
Also, page protection watchpoints work VERY POORLY for watching
anything on the stack, you really can't do that.
Jim
On Oct 25, 2004, at 12:59 AM, Jonas Maebe wrote:
On 25 okt 2004, at 00:59, Paul Sargent wrote:
Thing is..... OMG how slow is it? It says it's adding a hardware
watchpoint. If that's hardware.....!!!!! I have a feeling what I was
seeing before as a hang was just a very slow running program.
True hardware watchpoints are still not supported in the PPC version
of gdb afaik (even though (most?) ppc's has this capability). I think
it currently simply makes the page containing the watched data
read-only, and then after each segmentation fault checks whether the
watched data has changed.
If there are lots of other changes to the page containing the data you
are watching, this is indeed very slow. The old way where gdb always
used software watchpoints on ppc (single stepping through the program
and checking whether the watched value changed after each instruction)
was even worse though :)
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
email@hidden
Developer Tools - gdb
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden