[v5] Add negative repeat count to 'x' command

  On 08/08/2016 03:45 PM, Thomas Preudhomme wrote:
> Sorry for the late reply but I noticed an issue in the tests added by
> this patch for arm-none-eabi:
> 
> 
> FAIL: gdb.base/examine-backward.exp: address zero boundary: examine 3
> bytes forward from 0x0
> NA->FAIL: gdb.base/examine-backward.exp char-width=1, print-max=20 take
> 1 string backward (6/6)
> NA->FAIL: gdb.base/examine-backward.exp char-width=1, print-max=20 take
> 6 strings backward (pattern 1)
> 
> 
> The first one is a testism:
> 
> we match for: 0x\[0-9a-f\]+00.*:${byte}${byte}${byte}
> but we get: 0x0:    0x7f    0x45    0x4c
> 
> I'd thus suggest to match 0x\(\[0-9a-f\]+0\)?0 instead, with the right
> amount of escaping (I don't know whether ? needs escaping and why + does
> not need escaping in current pattern).

We're examining at 0x0.  Shouldn't we expect literally "0x0"
instead then?

> 
> 
> The other two seems like genuine errors. take 6 strings backward
> (pattern 1) gives:
> 
> gdb_expect_list pattern: /"ABCDEFGHIJKLMNOPQRST".../
> x/-6s^M
> 0x9aff <_fini+2>: "\277\370\274\b\274\236FpGABCDEFGHIJK"...^M
> 0x9b13 <TestStrings+11>:        "LMNOPQRSTUVWXYZ"^M
> 0x9b23 <TestStrings+27>:        ""^M
> 0x9b24 <TestStrings+28>:        ""^M
> 0x9b25 <TestStrings+29>:
> "\343\201\273\343\201\222\343\201\273\343\201\222"^M
> 0x9b32 <TestStrings+42>:        "01234567890123456789"...^M
> (gdb) FAIL: gdb.base/examine-backward.exp: char-width=1, print-max=20:
> take 6 strings backward (pattern 1)
> 
> 
> take 1 string backward (6/6) gives:
> 
> 0x9aff <_fini+2>: "\277\370\274\b\274\236FpGABCDEFGHIJK"...
> 
> 
> Please let me know what I can do to help diagnose this error.

The find-strings-backwards algorithm just looks back for '\0' to
find string boundaries.  Looks like it just happens that in your
case, the TestStrings array is immediately preceded by the
tail of _fini, with no gap in between.

Try this.  It's not strictly correct to assume that the linker
places the objects consecutively, but it's probably safe
in practice.
  

On 11/08/16 00:58, Pedro Alves wrote:
> On 08/08/2016 03:45 PM, Thomas Preudhomme wrote:
>> Sorry for the late reply but I noticed an issue in the tests added by
>> this patch for arm-none-eabi:
>>
>>
>> FAIL: gdb.base/examine-backward.exp: address zero boundary: examine 3
>> bytes forward from 0x0
>> NA->FAIL: gdb.base/examine-backward.exp char-width=1, print-max=20 take
>> 1 string backward (6/6)
>> NA->FAIL: gdb.base/examine-backward.exp char-width=1, print-max=20 take
>> 6 strings backward (pattern 1)
>>
>>
>> The first one is a testism:
>>
>> we match for: 0x\[0-9a-f\]+00.*:${byte}${byte}${byte}
>> but we get: 0x0:    0x7f    0x45    0x4c
>>
>> I'd thus suggest to match 0x\(\[0-9a-f\]+0\)?0 instead, with the right
>> amount of escaping (I don't know whether ? needs escaping and why + does
>> not need escaping in current pattern).
>
> We're examining at 0x0.  Shouldn't we expect literally "0x0"
> instead then?

That's what I would have done but I assumed that the test was passing on the 
machine it was developed and thus that some machine display 0x00000000 or something.

>
>>
>>
>> The other two seems like genuine errors. take 6 strings backward
>> (pattern 1) gives:
>>
>> gdb_expect_list pattern: /"ABCDEFGHIJKLMNOPQRST".../
>> x/-6s^M
>> 0x9aff <_fini+2>: "\277\370\274\b\274\236FpGABCDEFGHIJK"...^M
>> 0x9b13 <TestStrings+11>:        "LMNOPQRSTUVWXYZ"^M
>> 0x9b23 <TestStrings+27>:        ""^M
>> 0x9b24 <TestStrings+28>:        ""^M
>> 0x9b25 <TestStrings+29>:
>> "\343\201\273\343\201\222\343\201\273\343\201\222"^M
>> 0x9b32 <TestStrings+42>:        "01234567890123456789"...^M
>> (gdb) FAIL: gdb.base/examine-backward.exp: char-width=1, print-max=20:
>> take 6 strings backward (pattern 1)
>>
>>
>> take 1 string backward (6/6) gives:
>>
>> 0x9aff <_fini+2>: "\277\370\274\b\274\236FpGABCDEFGHIJK"...
>>
>>
>> Please let me know what I can do to help diagnose this error.
>
> The find-strings-backwards algorithm just looks back for '\0' to
> find string boundaries.  Looks like it just happens that in your
> case, the TestStrings array is immediately preceded by the
> tail of _fini, with no gap in between.
>
> Try this.  It's not strictly correct to assume that the linker
> places the objects consecutively, but it's probably safe
> in practice.

The patch works indeed. Thanks for your quick answer.

Best regards,

Thomas

>
> diff --git c/gdb/testsuite/gdb.base/examine-backward.c w/gdb/testsuite/gdb.base/examine-backward.c
> index b338503..187fad1 100644
> --- c/gdb/testsuite/gdb.base/examine-backward.c
> +++ w/gdb/testsuite/gdb.base/examine-backward.c
> @@ -32,6 +32,14 @@ literals.  The content of each array is the same as followings:
>    };
>  */
>
> +/* This is here just to ensure we have a null character before
> +   TestStrings, to avoid showing garbage when we look for strings
> +   backwards from TestStrings.  */
> +
> +const char NullString[] = {
> +  0x00
> +};
> +
>  const char TestStrings[] = {
>    0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48,
>    0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50,
>
>
  

Hi Pedro,

On 11/08/16 13:51, Thomas Preudhomme wrote:
>>
>> The find-strings-backwards algorithm just looks back for '\0' to
>> find string boundaries.  Looks like it just happens that in your
>> case, the TestStrings array is immediately preceded by the
>> tail of _fini, with no gap in between.
>>
>> Try this.  It's not strictly correct to assume that the linker
>> places the objects consecutively, but it's probably safe
>> in practice.
>
> The patch works indeed. Thanks for your quick answer.

While trying this I noticed that the following 2 tests fail when running with 
qemu-user (it works with qemu-system):

gdb.base/examine-backward.exp: address zero boundary: examine 6 bytes backward
gdb.base/examine-backward.exp: address zero boundary: examine 3 bytes backward 
from 0x0

They fail with:

0xfffffffd:     Cannot access memory at address 0xfffffffd

I suppose these two tests should also be guarded or maybe have several expected 
results.

Best regards,

Thomas
  

On 08/11/2016 03:08 PM, Thomas Preudhomme wrote:
>>
> 
> While trying this I noticed that the following 2 tests fail when running
> with qemu-user (it works with qemu-system):

So this is emulating a no-MMU configuration, right?  Since gdb managed to
read from address 0.  Otherwise, the problem is in is_address_zero_readable.

> 
> gdb.base/examine-backward.exp: address zero boundary: examine 6 bytes backward
> 
> gdb.base/examine-backward.exp: address zero boundary: examine 3 bytes
> backward from 0x0
> 
> They fail with:
> 
> 0xfffffffd:     Cannot access memory at address 0xfffffffd
> 
> I suppose these two tests should also be guarded or maybe have several
> expected results.

If you try reading from that address directly, does it work?
E.g. "x 0xfffffffd".

Wondering whether gdb is actually trying to read from 0xfffffffffffffffd,
and that failing somewhere.  The address print routine (paddress) trims
the upper 32-bits of CORE_ADDR when debugging a 32-bit target.

But probably this just means that that physical address really
does not exist on the emulated system, and so qemu's stub returns
error when gdb tries to read off of it?

Thanks,
Pedro Alves
  

On 11/08/16 17:32, Pedro Alves wrote:
> On 08/11/2016 03:08 PM, Thomas Preudhomme wrote:
>>>
>>
>> While trying this I noticed that the following 2 tests fail when running
>> with qemu-user (it works with qemu-system):
>
> So this is emulating a no-MMU configuration, right?  Since gdb managed to
> read from address 0.  Otherwise, the problem is in is_address_zero_readable.

qemu-system-user would be no MMU, qemu-user would have an MMU *but* the qemu gdb 
stub would bypass lots of memory access checks AFAIK.

>
>>
>> gdb.base/examine-backward.exp: address zero boundary: examine 6 bytes backward
>>
>> gdb.base/examine-backward.exp: address zero boundary: examine 3 bytes
>> backward from 0x0
>>
>> They fail with:
>>
>> 0xfffffffd:     Cannot access memory at address 0xfffffffd
>>
>> I suppose these two tests should also be guarded or maybe have several
>> expected results.
>
> If you try reading from that address directly, does it work?
> E.g. "x 0xfffffffd".

Same error: 0xfffffffd:     Cannot access memory at address 0xfffffffd

>
> Wondering whether gdb is actually trying to read from 0xfffffffffffffffd,
> and that failing somewhere.  The address print routine (paddress) trims
> the upper 32-bits of CORE_ADDR when debugging a 32-bit target.
>
> But probably this just means that that physical address really
> does not exist on the emulated system, and so qemu's stub returns
> error when gdb tries to read off of it?

Yes, I believe that's the case. For some reason reading from 0 works but not 
from the end of the address space. Why not use a multiple regex matching and 
make the test UNSUPPORTED with a new regex on this error message?

This is just a suggestion, I am not very familiar with how GDB deals with this 
kind of issue generally but have noticed testcases with several -re patterns.

Best regards,

Thomas
  

On 08/16/2016 03:03 PM, Thomas Preudhomme wrote:
> 
>>
>> Wondering whether gdb is actually trying to read from 0xfffffffffffffffd,
>> and that failing somewhere.  The address print routine (paddress) trims
>> the upper 32-bits of CORE_ADDR when debugging a 32-bit target.
>>
>> But probably this just means that that physical address really
>> does not exist on the emulated system, and so qemu's stub returns
>> error when gdb tries to read off of it?
> 
> Yes, I believe that's the case. For some reason reading from 0 works but
> not from the end of the address space. Why not use a multiple regex
> matching and
> make the test UNSUPPORTED with a new regex on this error message?
> 
> This is just a suggestion, I am not very familiar with how GDB deals
> with this
> kind of issue generally but have noticed testcases with several -re patterns.
> 

First I think we should assess whether the behavior is correct or
whether there's a qemu or gdb bug.  If it's a gdb bug, we should fix
it, of course.  If it's a qemu bug, we should report it and maybe XFAIL
it.  If it's not a bug but a qemu personality quirk, then we can make
the tests cope, somehow.

I still wonder why does the read from 0 work at all.  I've tried
reproducing this, using x86_64 Fedora 23's stock qemu-arm:

$ qemu-arm -version
qemu-arm version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard

... but couldn't.  Here's what I get instead:

Terminal 1:

 $ cat crash.c 
 int main ()
 {
   volatile int *null = 0; 

   return *null;
 }

 $ arm-linux-gnueabi -static crash.c

 $ qemu-arm -g 9999 a.out

Terminal 2:

 $ gdb a.out -ex "tar rem :9999"

 (gdb) x 0
 Sending packet: $m0,4#fd...Ack
 Packet received: E14
 0x0:    Cannot access memory at address 0x0

IIRC, arm's exception vector is at 0 and that that's
where execution starts.  But that shouldn't be applicable
to mmu userspace programs?

I wonder what's different between our environments.

Note: I had to use -static, because of:

 $ qemu-arm -g 9999  ./crash.arm 
 /lib/ld-linux.so.3: No such file or directory

I suppose I would need to point qemu at an arm sysroot,
somehow to get past that.

Is there a dejagnu board file somewhere handy one could steal
in order to run tests against qemu-user ?

Thanks,
Pedro Alves
  

Hi Pedro,

Sorry for the delay in answering.

On 19/08/16 19:59, Pedro Alves wrote:
>>
>
> First I think we should assess whether the behavior is correct or
> whether there's a qemu or gdb bug.  If it's a gdb bug, we should fix
> it, of course.  If it's a qemu bug, we should report it and maybe XFAIL
> it.  If it's not a bug but a qemu personality quirk, then we can make
> the tests cope, somehow.
>
> I still wonder why does the read from 0 work at all.  I've tried
> reproducing this, using x86_64 Fedora 23's stock qemu-arm:
>
> $ qemu-arm -version
> qemu-arm version 2.4.1 (qemu-2.4.1-11.fc23), Copyright (c) 2003-2008 Fabrice Bellard
>
> ... but couldn't.  Here's what I get instead:
>
> Terminal 1:
>
>  $ cat crash.c
>  int main ()
>  {
>    volatile int *null = 0;
>
>    return *null;
>  }
>
>  $ arm-linux-gnueabi -static crash.c
>
>  $ qemu-arm -g 9999 a.out
>
> Terminal 2:
>
>  $ gdb a.out -ex "tar rem :9999"
>
>  (gdb) x 0
>  Sending packet: $m0,4#fd...Ack
>  Packet received: E14
>  0x0:    Cannot access memory at address 0x0
>
> IIRC, arm's exception vector is at 0 and that that's
> where execution starts.  But that shouldn't be applicable
> to mmu userspace programs?

I'm getting:

(gdb) x 0
0x0:    0x464c457f

However note that I compiled with arm-none-eabi-gcc so there would be some bits 
of the program (ARM's exception vector indeed) at this address.

>
> I wonder what's different between our environments.

We are targetting ARM bare-metal targets.

>
> Note: I had to use -static, because of:
>
>  $ qemu-arm -g 9999  ./crash.arm
>  /lib/ld-linux.so.3: No such file or directory
>
> I suppose I would need to point qemu at an arm sysroot,
> somehow to get past that.
>
> Is there a dejagnu board file somewhere handy one could steal
> in order to run tests against qemu-user ?

Nothing public that I am aware of I'm afraid. However I can reproduce this issue 
easily by compiling examine-backward.c with the GNU ARM embedded toolchain [1] 
using the following command line:

arm-none-eabi-gcc -o examine-backward.axf 
gdb/testuite/gdb.base/examine-backward.c -specs=rdimon.specs

and then running:

qemu-arm -g 2048 examine-backward.axf &
arm-none-eabi-gdb examine-backward.axf
(gdb) target remote :2048
x/3xb 0x0
x/-6x


[1] https://launchpad.net/gcc-arm-embedded

Thanks for your effort on understanding this Pedro.

Best regards,

Thomas