This is the mail archive of the gdb@sourceware.cygnus.com 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]

Re: Hardware watchpoints



> I agree that using the value chain is fragile.  It's my impression
> that it was never intended for anything more than freeing old values.
> Nobody ever promised that it would have any specific semantics.
> 
> Instead of adding yet another special flag, we could change
> value_primitive_field, or whoever extracts bitfields, to create a new
> value object, also on the chain, containing just the words from the
> original value that hold the bitfield, and then let that smaller value
> become unlazy.

I corrected this problem slightly differently: by adding a condition
that a struct or array should never be watched, even if they are not
lazy, unless they appear at the head of the value chain, which means
the user explicitly asked to watch that struct or that array.

This didn't initially work, because it turns out that
value_primitive_field was not setting VALUE_OFFSET of the value it
created for the packed bitfield, so GDB was trying to watch a wrong
address.  I corrected that as well.

The diffs are quite large, so I send them to gdb-patches.  See my
message whose Subject is "Hardware watchpoints for bitfields".

Btw, watching bitfields is a bit tricky due to the code generated by a
compiler.  For example, given the following snippet:

  struct foo {
    int iv;
    double dv;
    unsigned flag1:1;
    unsigned flag2:2;
    int jv;
  } foo_var;
  ...
  foo_var.flag2 = 2;

GCC generates the following code for the last line:

  andb	$0xf9,0xfffffff0(%ebp)
  orb	$0x4,0xfffffff0(%ebp)

If we watch foo_var.flag2, and assuming its initial value was
different from 0, this hits the watchpoint twice: the first time GDB
announces its new value to be 0, the second time it announces a change
of value from 0 to 2.  Both of these changes happen in the same source
line.  This might confuse users unless they understand how bitfields
are implemented by the compiler.

Perhaps it is a good idea to mention this in the manual?

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