[pushed] Don't suppress errors inserting/removing hardware breakpoints in shared libraries.

Pedro Alves palves@redhat.com
Thu Jun 5 16:02:00 GMT 2014


On 06/03/2014 10:40 AM, Yao Qi wrote:
> On 04/23/2014 10:08 PM, Pedro Alves wrote:
>> +# Hardware breakpoints are implemented using a mechanism that is not
>> +# dependent on being able to modify the target's memory, we should be
>> +# able to set them even in unmapped memory areas.
>> +gdb_test "hbreak *0" "Hardware assisted breakpoint \[0-9\]+ at 0x0"
>> +
>> +gdb_test "info break" "hw breakpoint.*y.*0x0\+\[ \t\]\+" \
>> +    "info break shows hw breakpoint"
> 
> These two tests fail on arm-none-eabi target,
> 
> hbreak *0^M
> Hardware assisted breakpoint 3 at 0x0: file
> /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S,
> line 25.^M
> (gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0
> info break^M
> Num     Type           Disp Enb Address    What^M
> 3       hw breakpoint  keep y   0x00000000
> /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M
> (gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint
> delete $bpnum
> 
> because the vector table base address is 0x0.
> 
> We can either relax the regex pattern or skip this test on bare metal
> targets.  However, after I read the commit log, I find
> hbreak-unmapped.exp isn't necessary because we've already had
> hbreak-in-shr-unsupported.exp.  I don't see anything hbreak-unmapped.exp
> can cover while hbreak-in-shr-unsupported.exp doesn't.  I suggest we

They're opposites.  The real tests are not the "hbreak main" parts,
which is the tests probing target features, but what follows.  The
former tests that inserting a hbreak in an unmapped region
doesn't error.  While the latter tests that inserting a hbreak in
a mapped region when the target doesn't support hbreak at all
results in an error.

>  2) or skip hbreak-unmapped.exp on bare metal and uclinux targets,

Yes, but no need to match by target, we can do like e.g.,
gdb.base/signull.exp does, and check whether "x /b 0" manages
to read memory.  If so, then skip the test.  Any sane target with
an MMU will leave page 0 unmapped, so no need to look for some other
address.

-- 
Pedro Alves



More information about the Gdb-patches mailing list