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

[Yao Qi <yao at codesourcery dot com>]

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

 1) remove hbreak-unmapped.exp and hbreak-unmapped.c
 2) or skip hbreak-unmapped.exp on bare metal and uclinux targets,
 3) or relax the pattern

What do you think?

-- 
Yao (éå)