[Bug gdb/18208] New: Fails in gdb.base/coredump-filter.exp in remote testing

[Bug gdb/18208] New: Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

            Bug ID: 18208
           Summary: Fails in gdb.base/coredump-filter.exp in remote
                    testing
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: qiyao at gcc dot gnu.org

I see the following fails in the remote testing on aarch64-linux-gnu, but they
don't fail on native testing on aarch64-linux-gnu.

print/x *(char *) 0x7fb7ff6000^M
Cannot access memory at address 0x7fb7ff6000^M
(gdb) FAIL: gdb.base/coredump-filter.exp: loading and testing corefile for
non-Private-Anonymous: print/x *shared_anon ( = 0x22)

x/i $pc^M
=> 0x400b3c:    Cannot access memory at address 0x400b3c^M
(gdb) FAIL: gdb.base/coredump-filter.exp: disassembling function main for
non-Private-Anonymous: no binary: disassemble function with corefile and
without a binary

print/x *(char *) 0x7fb7ff7000^M
Cannot access memory at address 0x7fb7ff7000^M
(gdb) FAIL: gdb.base/coredump-filter.exp: loading and testing corefile for
non-Shared-Anonymous: print/x *private_anon ( = 0x11)

x/i $pc^M
=> 0x400b3c:    Cannot access memory at address 0x400b3c^M
(gdb) FAIL: gdb.base/coredump-filter.exp: disassembling function main for
non-Shared-Anonymous: no binary: disassemble function with corefile and without
a binary

print/x *(char *) 0x7fb7ff6000^M
Cannot access memory at address 0x7fb7ff6000^M
(gdb) FAIL: gdb.base/coredump-filter.exp: loading and testing corefile for
DoNotDump: print/x *shared_anon ( = 0x22)

x/i $pc^M
=> 0x400b3c:    Cannot access memory at address 0x400b3c^M
(gdb) FAIL: gdb.base/coredump-filter.exp: disassembling function main for
DoNotDump: no binary: disassemble function with corefile and without a binary

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64-linux-gnu

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
Both native testing and remote testing are running on the same aarch64 board,
but the generated corefile is different,

On native, the file is large, and has more sections,
$ ls ./testsuite/gdb.base/non-shared-anon.gcore -lh
-rw-rw-r-- 1 yaoqi01 yaoqi01 1.6M Apr  7 11:51
./testsuite/gdb.base/non-shared-anon.gcore

(gdb) maintenance info sections
....
Core file:
   
`/home/yaoqi01/SourceCode/gnu/build-gdb/gdb/./testsuite/gdb.base/non-shared-anon.gcore',
file type elf64-littleaarch64.
 [0]     0x00000000->0x00000928 at 0x000003c0: note0 READONLY HAS_CONTENTS
 [1]     0x00000000->0x00000110 at 0x000004e0: .reg/4741 HAS_CONTENTS
 [2]     0x00000000->0x00000110 at 0x000004e0: .reg HAS_CONTENTS
 [3]     0x00000000->0x00000210 at 0x0000060c: .reg2/4741 HAS_CONTENTS
 [4]     0x00000000->0x00000210 at 0x0000060c: .reg2 HAS_CONTENTS
 [5]     0x00000000->0x00000080 at 0x00000830: .note.linuxcore.siginfo/4741
HAS_CONTENTS
---Type <return> to continue, or q <return> to quit---
 [6]     0x00000000->0x00000080 at 0x00000830: .note.linuxcore.siginfo
HAS_CONTENTS
 [7]     0x00000000->0x00000130 at 0x000008c4: .auxv HAS_CONTENTS
 [8]     0x00000000->0x000002e0 at 0x00000a08: .note.linuxcore.file/4741
HAS_CONTENTS
 [9]     0x00000000->0x000002e0 at 0x00000a08: .note.linuxcore.file
HAS_CONTENTS
 [10]     0x00400000->0x00401000 at 0x00000ce8: load1 ALLOC LOAD READONLY CODE
HAS_CONTENTS
 [11]     0x00410000->0x00411000 at 0x00001ce8: load2 ALLOC LOAD READONLY CODE
HAS_CONTENTS
 [12]     0x00411000->0x00412000 at 0x00002ce8: load3 ALLOC LOAD CODE
HAS_CONTENTS
 [13]     0x2000000000->0x200001b000 at 0x00003ce8: load4 ALLOC LOAD READONLY
CODE HAS_CONTENTS
 [14]     0x200001b000->0x200001d000 at 0x0001ece8: load5 ALLOC LOAD READONLY
CODE HAS_CONTENTS
 [15]     0x200001d000->0x2000020000 at 0x00020ce8: load6 ALLOC LOAD CODE
HAS_CONTENTS
 [16]     0x2000028000->0x200002a000 at 0x00023ce8: load7 ALLOC LOAD CODE
HAS_CONTENTS
 [17]     0x200002b000->0x200002c000 at 0x00025ce8: load8 ALLOC LOAD READONLY
CODE HAS_CONTENTS
 [18]     0x200002c000->0x200002e000 at 0x00026ce8: load9 ALLOC LOAD CODE
HAS_CONTENTS
 [19]     0x200002e000->0x200015f000 at 0x00028ce8: load10 ALLOC LOAD READONLY
CODE HAS_CONTENTS
 [20]     0x200015f000->0x200016e000 at 0x00159ce8: load11 ALLOC LOAD READONLY
HAS_CONTENTS
 [21]     0x200016e000->0x2000172000 at 0x00168ce8: load12 ALLOC LOAD READONLY
CODE HAS_CONTENTS
 [22]     0x2000172000->0x2000174000 at 0x0016cce8: load13 ALLOC LOAD CODE
HAS_CONTENTS
 [23]     0x2000174000->0x2000178000 at 0x0016ece8: load14 ALLOC LOAD CODE
HAS_CONTENTS
 [24]     0x7ffffdf000->0x8000000000 at 0x00172ce8: load15 ALLOC LOAD CODE
HAS_CONTENTS

However, on remote testing, the corefile is small and only has one "load*"
section.

$ ls -lh ./testsuite/gdb.base/non-shared-anon.gcore
-rw-rw-r-- 1 yao yao 10K Apr  7 12:37
./testsuite/gdb.base/non-shared-anon.gcore
(gdb) maintenance info sections
...
Core file:
   
`/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/./testsuite/gdb.base/non-shared-anon.gcore',
file type elf64-littleaarch64.
 [0]     0x00000000->0x00000634 at 0x000000b0: note0 READONLY HAS_CONTENTS
 [1]     0x00000000->0x00000110 at 0x000001d0: .reg/4643 HAS_CONTENTS
 [2]     0x00000000->0x00000110 at 0x000001d0: .reg HAS_CONTENTS
 [3]     0x00000000->0x00000210 at 0x000002fc: .reg2/4643 HAS_CONTENTS
 [4]     0x00000000->0x00000210 at 0x000002fc: .reg2 HAS_CONTENTS
 [5]     0x00000000->0x00000080 at 0x00000520: .note.linuxcore.siginfo/4643
HAS_CONTENTS
 [6]     0x00000000->0x00000080 at 0x00000520: .note.linuxcore.siginfo
HAS_CONTENTS
 [7]     0x00000000->0x00000130 at 0x000005b4: .auxv HAS_CONTENTS
 [8]     0x7fb7ffc000->0x7fb7ffe000 at 0x000006e4: load1 ALLOC LOAD READONLY
CODE HAS_CONTENTS

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[palves at redhat dot com]

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

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Maybe the:

    remote_exec target "sh -c \"echo $filter_flag >
/proc/$ipid/coredump_filter\""

line isn't working as intended?

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[sergiodj at redhat dot com]

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

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergiodj at redhat dot com

--- Comment #3 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
According to BuildBot:

  <https://sourceware.org/ml/gdb-testers/2015-q2/msg00004.html>

I don't see this test failing on any native-*-gdbserver variant (the patch
failed to compile on Fedora, but this has been fixed by an obvious commit).

I will see if I can test this on an aarch64 machine and reproduce the problem.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[sergiodj at redhat dot com]

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

--- Comment #4 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
Hey Yao, I managed to test this on an aarch64 machine, and I cannot reproduce
the issue.  I ran the test using the native-gdbserver,
native-extended-gdbserver and native-stdio-gdbserver boards, and everything is
passing.

What is the GNU/Linux distro being used?  Does the Linux kernel being used
provides the "VmFlags:" field in the /proc/PID/smaps file?

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

--- Comment #5 from Yao Qi <qiyao at gcc dot gnu.org> ---
I am running testing for aarch64-linux-gnu target on x86_64 machine, and they
are connected via ssh.

After this remote_exec,

 remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""

I dump the /proc/$ipid/coredump_filter via cat, and it becomes 00000000, which
is a surprise to me.  Dejagnu does remote_exec on build like this,

$ ssh -l yaoqi01 linaro-junor1-1 sh -c 'echo 0x7e > /proc/6160/coredump_filter'

and on target, coredump_filter is zero.

$ cat /proc/6160/coredump_filter 
00000000

However, I remove "sh -c", like:

$ /usr/bin/ssh -l yaoqi01 linaro-junor1-1 'echo 0x7e >
/proc/6160/coredump_filter'

then the coredump_filter is correctly set,

$ cat /proc/6160/coredump_filter 
0000007e

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[palves at redhat dot com]

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

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
> remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
>
> I dump the /proc/$ipid/coredump_filter via cat, and it becomes 00000000, which is a surprise to me.  Dejagnu does remote_exec on build like this,

> $ ssh -l yaoqi01 linaro-junor1-1 sh -c 'echo 0x7e > /proc/6160/coredump_filter'

Did you try the exact above manually?  Because 00000000 is what would happen if 
$filter_flag was lost along the way somewhere, resulting in:

   echo > /proc/6160/coredump_filter

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[palves at redhat dot com]

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

--- Comment #7 from Pedro Alves <palves at redhat dot com> ---
Oh, I see something like that here too:

 $ ssh localhost sh -c 'echo foo > /tmp/foo'
 $ cat /tmp/foo 
 $

But:

 $ ssh localhost 'sh -c "echo bar > /tmp/foo"'
 $ cat /tmp/foo 
 bar
 $

The difference is that the '' surrounds the whole sh command.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[palves at redhat dot com]

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

--- Comment #8 from Pedro Alves <palves at redhat dot com> ---
BTW, we have other similar uses of sh -c in the tree:

$ grep remote_exec -rn | grep "sh -"
gdb.base/coredump-filter.exp:34:    remote_exec target "sh -c \"echo
$filter_flag > /proc/$ipid/coredump_filter\""
gdb.trace/strace.exp:76:    set status [remote_exec target "sh -c { \[ -S
$socket_file \] }"]
gdb.trace/strace.exp:98:        set status [remote_exec target "sh -c { \[ -S
$socket_file \] }"]
gdb.trace/strace.exp:116:       remote_exec target "sh -c \"rm -r
$socket_file\""
gdb.dwarf2/dw2-dir-file-name.exp:359:remote_exec host "sh -c \"rm -f
$filelist\""
gdb.dwarf2/dw2-dir-file-name.exp:360:remote_exec host "sh -c \"rmdir
$dirremovelist\""
gdb.dwarf2/dw2-dir-file-name.exp:361:remote_exec host "sh -c \"mkdir
$dircreatelist\""
gdb.dwarf2/dw2-dir-file-name.exp:362:remote_exec host "sh -c \"for d in
$dircreatelist; do cp ${srcdir}/${subdir}/${srcfile} \\\$d/${srctmpfile};
done\""

so it sounds like the issue may be on your board file.  I haven't tried it
through a board file myself though.  We should probably have a board file that
does real remote gdbserver testing against localhost...

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

--- Comment #9 from Yao Qi <qiyao at gcc dot gnu.org> ---
(In reply to Pedro Alves from comment #8)

> so it sounds like the issue may be on your board file.  I haven't tried it
> through a board file myself though.  We should probably have a board file
> that does real remote gdbserver testing against localhost...

Maybe, I hacked the test case to set /proc/PID/coredump_filter in the C code,

int
set_coredump_filter (int pid, int bits)
{
  char cmd[80];

  snprintf(cmd, sizeof cmd, "echo %d > /proc/%d/coredump_filter", bits, pid);
  return system (cmd);
}

and call set_coredump_filter in gdb like this,

gdb_test "p set_coredump_filter (${ipid}, ${filter_flag})" " = 0"

all the fails go away.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[sergiodj at redhat dot com]

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

--- Comment #10 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
(In reply to Pedro Alves from comment #8)
> BTW, we have other similar uses of sh -c in the tree:

My first attempt was to do:

  remote_exec target "echo 0x123 > /file"

But that failed.  So, I searched in the tree and found those examples that
Pedro mentioned.  Therefore, if the coredump_filter.exp test is failing, I
wouldn't be surprised if those other tests are failing as well.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Yao Qi <qiyao@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8dbe7ca5a5755274fca1d3021ad648a1575e66cb

commit 8dbe7ca5a5755274fca1d3021ad648a1575e66cb
Author: Yao Qi <yao.qi@linaro.org>
Date:   Fri Apr 24 11:00:14 2015 +0100

    A new board file remote-gdbserver-on-localhost.exp

    This patch is to add a new board file that does real remote gdbserver
    testing on localhost.  This board file can be used to reproduce PR 18208.

    gdb/testsuite

    2015-04-24  Yao Qi  <yao.qi@linaro.org>

        * boards/remote-gdbserver-on-localhost.exp: New file.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

--- Comment #12 from Yao Qi <qiyao at gcc dot gnu.org> ---
These fails can be reproduced using remote-gdbserver-on-localhost board file.

 $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost
coredump-filter.exp'

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Yao Qi <qiyao@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=422349a385c2ccfc1e66f5c65560e5bd5fc97953

commit 422349a385c2ccfc1e66f5c65560e5bd5fc97953
Author: Yao Qi <yao.qi@linaro.org>
Date:   Fri May 8 12:37:48 2015 +0100

    Fix PR 18208: update /proc/pid/coredump_filter by c code

    Hi,
    We see some fails in gdb.base/coredump-filter.exp when we do remote
    gdbserver testing, like what I did for arm/aarch64 linux testing or
    run it with board file remote-gdbserver-on-localhost

     $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost
coredump-filter.exp'

    we find that this line in the test doesn't work as expected,

     remote_exec target "sh -c \"echo $filter_flag >
/proc/$ipid/coredump_filter\""

    although such pattern has been used in gdb testsuite somewhere else,
    but the special thing here is that we redirect the output to
    /proc/$ipid/coredump_filter on the remote target.  DejaGNU will
    redirect the output from the remote target to local, and looks tcl
    gets confused by these two redirection.

    After trying pass different parameters to remote_exec and hacking
    remote_exec/rsh_exec/local_exec, I got no success, I decide
    to give up, and try to update /proc/$ipid/coredump_filter by the c
    code directly.

    This patch adds a c function set_coredump_filter to update
    coredump_filter, and GDB calls it.

    gdb/testsuite:

    2015-05-08  Yao Qi  <yao.qi@linaro.org>

        PR gdb/18208
        * gdb.base/coredump-filter.c (set_coredump_filter): New function.
        * gdb.base/coredump-filter.exp (do_save_core): Call inferior
        function set_coredump_filter, and remove remote_exec call.
        Remove argument ipid.  Callers update.
        (top level): Don't get inferior's PID.

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

[Bug gdb/18208] Fails in gdb.base/coredump-filter.exp in remote testing

[qiyao at gcc dot gnu.org]

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

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Yao Qi <qiyao at gcc dot gnu.org> ---
Close it.

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