Re: [PATCH] Harden gdb.base/bp-permanent.exp

Luis Machado
2015-04-13T17:51:21Z

On 04/10/2015 11:02 AM, Luis Machado wrote:
> On 04/10/2015 07:04 AM, Pedro Alves wrote:
>> On 04/09/2015 06:10 PM, Luis Machado wrote:
>>
>>> diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp
>>> b/gdb/testsuite/gdb.base/bp-permanent.exp
>>> index 81a5293..9193db8 100644
>>> --- a/gdb/testsuite/gdb.base/bp-permanent.exp
>>> +++ b/gdb/testsuite/gdb.base/bp-permanent.exp
>>> @@ -104,7 +104,18 @@ proc test {always_inserted sw_watchpoint} {
>>> # to memory manually.
>>> set count [expr $address_after_bp - $address_bp]
>>> for {set i 0} {$i < $count} {incr i} {
>>> - gdb_test "p /x addr_bp\[$i\] = buffer\[$i\]" " = .*"
>>> + gdb_test_multiple "p /x addr_bp\[$i\] = buffer\[$i\]" $test {
>>> + -re "Cannot access memory at address $hex.*$gdb_prompt $" {
>>> + # Some targets (QEMU for one) do not allow writes to the
>>> + # .text section. It is no use continuing with the test
>>> + # at this point. Just return.
>>
>> Double space after period.
>>
>>> + unsupported $test
>>
>> Something like:
>>
>> unsupported "Cannot access memory"
>>
>
> Did you mean untested here also?
>
> I went with "Cannot modify memory" to make the obstacle more explicit. I
> also modified the comment a bit to make it clear what we are dealing
> with. I'm sure older QEMU's worked in this regard, but more recent ones
> have stack protection, for example, that will lead to these failures.
>
>> OK with those changes.
>>
>
> Attached is what i plan to push later (pending the unsupported/untested
> nit above).
>

I've pushed this now.