[Bug gdb/21927] New: Searching memory on remote target fails

["dominik.b.czarnota+bugzilla at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21927

            Bug ID: 21927
           Summary: Searching memory on remote target fails
           Product: gdb
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dominik.b.czarnota+bugzilla at gmail dot com
  Target Milestone: ---

Hey,

There is a bug when searching memory on remote targets.
At least that is what happened for me on some x86-64 binaries.
My setup can be seen at the end of the post.

You can see the bug on this asciinema cast which connects to remote target
hosted as `gdbserver localhost:4444 /bin/ls`:
https://asciinema.org/a/o4ZCjQ7MRwyIKDx6uZHCcQCU9


This can be reproduced using a super simple hello world binary:
```
#include <stdio.h>

int main() {
    puts("Hello world");
}
```

That is compiled as `gcc main.c` (gcc version and file properties below).

Then starting a gdbserver as `gdbserver localhost:4444 ./a.out` and then in
another console:
```
$ gdb ./a.out -q
Reading symbols from ./a.out...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to
access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
0x00007feb9f0adcc0 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x10000067e
(gdb) c
Continuing.
Reading /usr/lib/libc.so.6 from remote target...

Breakpoint 1, 0x000000010000067e in main ()
(gdb) x/4i $rip
=> 0x10000067e <main+4>:        lea    0x9f(%rip),%rdi        # 0x100000724
   0x100000685 <main+11>:       callq  0x100000550 <puts@plt>
   0x10000068a <main+16>:       mov    $0x0,%eax
   0x10000068f <main+21>:       pop    %rbp
(gdb) ni
0x0000000100000685 in main ()
(gdb) i r rdi
rdi            0x100000724      4294969124
(gdb) x/s 0x100000724
0x100000724:    "Hello world"
(gdb) find 0x100000700, +0x50, "Hello"
Pattern not found.
(gdb) find 0x100000700, +200, "ello"
Pattern not found.
(gdb) 
(gdb) py import gdb; print(gdb.selected_inferior().search_memory(0x100000700,
500, "Hello"))
4294969124
(gdb) p/x 4294969124
$1 = 0x100000724
(gdb) find 0x100000700, +500, "Hello"
Pattern not found.
```

As you can see, the pattern is not found with `find` command and it really *is
there*.

On the other hand it was found by Python API - which is weird to me because I
started digging over this bug due to `gdb.selected_inferior().search_memory`
not being able to find my address.

Here is another asciicinema - for /bin/ls - showing that the Python's
`.search_memory` can show something weird as well:
https://asciinema.org/a/yAiyeTuagKL4r8CQ7FkMA4xJ5

As it returned an address which is unacessible.


Below you can see my gdb version.

```
$ gdb --version
GNU gdb (GDB) 8.0
// (...)

$ gdbserver --version
GNU gdbserver (GDB) 8.0
// (...)

$ gdb
(gdb) py import sys; print(sys.version)
3.6.2 (default, Jul 20 2017, 03:52:27) 
[GCC 7.1.1 20170630]

$ gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --with-expat
             --with-gdb-datadir=/usr/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/lib/gdb (relocatable)
             --without-libunwind-ia64
             --with-lzma
             --with-python=/usr (relocatable)
             --with-guile
             --with-separate-debug-dir=/usr/lib/debug (relocatable)
             --with-system-gdbinit=/etc/gdb/gdbinit
             --without-babeltrace

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
```

My gcc version:
```
$ gcc --version
gcc (GCC) 7.1.1 20170630
// (...)
```

The result `a.out` file properties:
```
$ file a.out 
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=6401e4473f83c5f4d6d5bffa691a69119ae86977, not stripped
$ checksec -f a.out
RELRO           STACK CANARY      NX            PIE             RPATH     
RUNPATH      FORTIFY Fortified Fortifiable  FILE
Partial RELRO   No canary found   NX enabled    PIE enabled     No RPATH   No
RUNPATH   No      0               0       a.out
```

Thanks,
Disconnect3d

-- 
You are receiving this mail because:
You are on the CC list for the bug.