This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rwatchpoint configuration


>
> For now, you could try a workaround: put two watchpoints on the same
> expression: one an rwatch (the one you wanted), the other a write
> watchpoint whose `commands' say just "continue".  This should cause GDB
> to note the changed value when it is written into the variable(s), so
> when the rwatch triggers it will see the known value and stop.
>
> Please see if this works for you.  If it doesn't, please tell more
> details.
>

This will probably sound like an ugly hack, but I ended up just
commenting out the logic that checks to see if the value has changed
in the case of a read breakpoint. So I bypass this issue at compile
time.

Setting an rwatch and a watch will work, but it wastes an additional
watchpoint resource (which is scarce on MicroBlaze). Plus gdb is being
used via Eclipse in this particular environment which would
necessitate changes in a bunch of other places to seamlessly do this.

My interaction with gdb code has been limited to minor target specific
bugfixes, so I probably do not understand all the ramifications to
propose a good solution. However, it seems to me that it should be
possible to make this check conditional at runtime based on some field
in current_target..say
current_target->target_supports_true_read_watchpoints.

-Siva


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]