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

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

[Yao Qi]

From: Yao Qi <yao.qi@linaro.org>

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.

Now this test passes on boardfile unix, native-gdbserver and
remote-gdbserver-on-localhost.  It also passes my board files for arm
and aarch64 testing.

gdb/testsuite:

2015-04-24  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.
---
 gdb/testsuite/gdb.base/coredump-filter.c   | 16 ++++++++++++++++
 gdb/testsuite/gdb.base/coredump-filter.exp | 15 ++++++---------
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/gdb/testsuite/gdb.base/coredump-filter.c b/gdb/testsuite/gdb.base/coredump-filter.c
index 192c469..18b9d9c 100644
--- a/gdb/testsuite/gdb.base/coredump-filter.c
+++ b/gdb/testsuite/gdb.base/coredump-filter.c
@@ -59,3 +59,19 @@ main (int argc, char *argv[])
 
   return 0; /* break-here */
 }
+
+/* Write V to /proc/self/coredump_filter.  Return 0 on success.  */
+
+int
+set_coredump_filter (int v)
+{
+  FILE *f = fopen("/proc/self/coredump_filter", "r+");
+
+  if (f == NULL)
+    return 1;
+
+  fprintf(f, "%#x", v);
+
+  fclose (f);
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.base/coredump-filter.exp b/gdb/testsuite/gdb.base/coredump-filter.exp
index f872de0..dbebaf0 100644
--- a/gdb/testsuite/gdb.base/coredump-filter.exp
+++ b/gdb/testsuite/gdb.base/coredump-filter.exp
@@ -34,10 +34,10 @@ if { ![runto_main] } {
 gdb_breakpoint [gdb_get_line_number "break-here"]
 gdb_continue_to_breakpoint "break-here" ".* break-here .*"
 
-proc do_save_core { filter_flag core ipid } {
-    verbose -log "writing $filter_flag to /proc/$ipid/coredump_filter"
+proc do_save_core { filter_flag core } {
+    verbose -log "writing $filter_flag to /proc/<inferior pid>/coredump_filter"
 
-    remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
+    gdb_test "p set_coredump_filter ($filter_flag)" " = 0"
 
     # Generate a corefile.
     gdb_gcore_cmd "$core" "save corefile"
@@ -146,11 +146,8 @@ if { !$core_supported } {
     return -1
 }
 
-# Get the inferior's PID.
-set infpid ""
 gdb_test_multiple "info inferiors" "getting inferior pid" {
-    -re "process \($decimal\).*\r\n$gdb_prompt $" {
-	set infpid $expect_out(1,string)
+    -re "process $decimal.*\r\n$gdb_prompt $" {
     }
     -re "Remote target.*$gdb_prompt $" {
 	# If the target does not provide PID information (like usermode QEMU),
@@ -184,12 +181,12 @@ foreach item $all_anon_corefiles {
 # Generate corefiles for the "anon" case.
 foreach item $all_anon_corefiles {
     with_test_prefix "saving corefile for [lindex $item 0]" {
-	do_save_core [lindex $item 1] [subst [lindex $item 2]] $infpid
+	do_save_core [lindex $item 1] [subst [lindex $item 2]]
     }
 }
 
 with_test_prefix "saving corefile for non-Private-Shared-Anon-File" {
-    do_save_core "0x60" $non_private_shared_anon_file_core $infpid
+    do_save_core "0x60" $non_private_shared_anon_file_core
 }
 
 clean_restart $testfile
-- 
1.9.1

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Pedro Alves]

On 04/24/2015 04:28 PM, Yao Qi wrote:

> 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.

Not sure what exactly gets confused either.

> 
> 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.

Probably the right fix would be for dejagnu to put ''s around
the whole sh -c command in rsh_exec:

    set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout]

dunno if that would work with real rsh.  Alternatively, teach
dejagnu about a real ssh mode...

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

This is fine with me.

> Now this test passes on boardfile unix, native-gdbserver and
> remote-gdbserver-on-localhost.  It also passes my board files for arm
> and aarch64 testing.


>      # Generate a corefile.
>      gdb_gcore_cmd "$core" "save corefile"
> @@ -146,11 +146,8 @@ if { !$core_supported } {
>      return -1
>  }
>  
> -# Get the inferior's PID.
> -set infpid ""
>  gdb_test_multiple "info inferiors" "getting inferior pid" {
> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
> -	set infpid $expect_out(1,string)
> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>      }
>      -re "Remote target.*$gdb_prompt $" {
>  	# If the target does not provide PID information (like usermode QEMU),

This "If the target does not provide PID information" check sounds
odd now.  Do we still need it?

Thanks,
Pedro Alves

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Luis Machado]

On 05/06/2015 01:12 PM, Pedro Alves wrote:
> On 04/24/2015 04:28 PM, Yao Qi wrote:
>
>> 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.
>
> Not sure what exactly gets confused either.
>
>>
>> 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.
>
> Probably the right fix would be for dejagnu to put ''s around
> the whole sh -c command in rsh_exec:
>
>      set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout]
>
> dunno if that would work with real rsh.  Alternatively, teach
> dejagnu about a real ssh mode...
>
>>
>> This patch adds a c function set_coredump_filter to update
>> coredump_filter, and GDB calls it.
>>
>
> This is fine with me.
>
>> Now this test passes on boardfile unix, native-gdbserver and
>> remote-gdbserver-on-localhost.  It also passes my board files for arm
>> and aarch64 testing.
>
>
>>       # Generate a corefile.
>>       gdb_gcore_cmd "$core" "save corefile"
>> @@ -146,11 +146,8 @@ if { !$core_supported } {
>>       return -1
>>   }
>>
>> -# Get the inferior's PID.
>> -set infpid ""
>>   gdb_test_multiple "info inferiors" "getting inferior pid" {
>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>> -	set infpid $expect_out(1,string)
>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>       }
>>       -re "Remote target.*$gdb_prompt $" {
>>   	# If the target does not provide PID information (like usermode QEMU),
>
> This "If the target does not provide PID information" check sounds
> odd now.  Do we still need it?

If we're not dealing with PID's, i don't think so.

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Yao Qi]

Luis Machado <lgustavo@codesourcery.com> writes:

>>> -# Get the inferior's PID.
>>> -set infpid ""
>>>   gdb_test_multiple "info inferiors" "getting inferior pid" {
>>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>>> -	set infpid $expect_out(1,string)
>>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>>       }
>>>       -re "Remote target.*$gdb_prompt $" {
>>>   	# If the target does not provide PID information (like usermode QEMU),
>>
>> This "If the target does not provide PID information" check sounds
>> odd now.  Do we still need it?
>
> If we're not dealing with PID's, i don't think so.

At the very start, I removed this block, but I recall that this block is
used as a guard for usermode QEMU which doesn't provide PID
information.  With this patch applied, we'll access
/proc/self/coredump_filter, but I am afraid it doesn't work as expected
on usermode QEMU, because usermode QEMU just intercepts few /proc
accesses and pass most of them through the host linux.  Accessing
/proc/QEMU_PID/coredump_filter isn't what we want in this test, so I
think it's better to skip the test for usermode QEMU.

Of course, I don't mind removing this block.  Luis, could you try this
patch and remove this block, see whether it causes fails on usermode QEMU?

-- 
Yao (齐尧)

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Luis Machado]

On 05/07/2015 06:05 AM, Yao Qi wrote:
> Luis Machado <lgustavo@codesourcery.com> writes:
>
>>>> -# Get the inferior's PID.
>>>> -set infpid ""
>>>>    gdb_test_multiple "info inferiors" "getting inferior pid" {
>>>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>>>> -	set infpid $expect_out(1,string)
>>>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>>>        }
>>>>        -re "Remote target.*$gdb_prompt $" {
>>>>    	# If the target does not provide PID information (like usermode QEMU),
>>>
>>> This "If the target does not provide PID information" check sounds
>>> odd now.  Do we still need it?
>>
>> If we're not dealing with PID's, i don't think so.
>
> At the very start, I removed this block, but I recall that this block is
> used as a guard for usermode QEMU which doesn't provide PID
> information.  With this patch applied, we'll access
> /proc/self/coredump_filter, but I am afraid it doesn't work as expected
> on usermode QEMU, because usermode QEMU just intercepts few /proc
> accesses and pass most of them through the host linux.  Accessing
> /proc/QEMU_PID/coredump_filter isn't what we want in this test, so I
> think it's better to skip the test for usermode QEMU.
>
> Of course, I don't mind removing this block.  Luis, could you try this
> patch and remove this block, see whether it causes fails on usermode QEMU?
>

Yeah, that sounds problematic. I'll give it a try and will let you know.

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Luis Machado]

On 05/07/2015 07:44 AM, Luis Machado wrote:
> On 05/07/2015 06:05 AM, Yao Qi wrote:
>> Luis Machado <lgustavo@codesourcery.com> writes:
>>
>>>>> -# Get the inferior's PID.
>>>>> -set infpid ""
>>>>>    gdb_test_multiple "info inferiors" "getting inferior pid" {
>>>>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>>>>> -    set infpid $expect_out(1,string)
>>>>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>>>>        }
>>>>>        -re "Remote target.*$gdb_prompt $" {
>>>>>        # If the target does not provide PID information (like
>>>>> usermode QEMU),
>>>>
>>>> This "If the target does not provide PID information" check sounds
>>>> odd now.  Do we still need it?
>>>
>>> If we're not dealing with PID's, i don't think so.
>>
>> At the very start, I removed this block, but I recall that this block is
>> used as a guard for usermode QEMU which doesn't provide PID
>> information.  With this patch applied, we'll access
>> /proc/self/coredump_filter, but I am afraid it doesn't work as expected
>> on usermode QEMU, because usermode QEMU just intercepts few /proc
>> accesses and pass most of them through the host linux.  Accessing
>> /proc/QEMU_PID/coredump_filter isn't what we want in this test, so I
>> think it's better to skip the test for usermode QEMU.
>>
>> Of course, I don't mind removing this block.  Luis, could you try this
>> patch and remove this block, see whether it causes fails on usermode
>> QEMU?
>>
>
> Yeah, that sounds problematic. I'll give it a try and will let you know.

Removing that conditional block i get 14 FAIL's, so it doesn't look like 
this test is suited for usermode QEMU.

Besides that, without the conditional block i also see a problem with 
the existing testcase using coredump_var_addr as an array but declaring 
it as a regular variable. It causes a number of errors. Did you notice 
that? Maybe it is specific to a certain version of expect.

# Obtain the address of each variable that will be checked on each
# case.
set coredump_var_addr ""
foreach item $all_anon_corefiles {
     foreach name [list [lindex $item 3] [lindex $item 4]] {
         set test "print/x $name"
         gdb_test_multiple $test $test {
             -re " = \($hex\)\r\n$gdb_prompt $" {
                 set coredump_var_addr($name) $expect_out(1,string)
             }
         }
     }
}

[PATCH] Fix coredump-filter.exp by correctly unsetting array (was: Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code)

[Sergio Durigan Junior]

On Thursday, May 07 2015, Luis Machado wrote:

> Besides that, without the conditional block i also see a problem with
> the existing testcase using coredump_var_addr as an array but
> declaring it as a regular variable. It causes a number of errors. Did
> you notice that? Maybe it is specific to a certain version of expect.
>
> # Obtain the address of each variable that will be checked on each
> # case.
> set coredump_var_addr ""
> foreach item $all_anon_corefiles {
>     foreach name [list [lindex $item 3] [lindex $item 4]] {
>         set test "print/x $name"
>         gdb_test_multiple $test $test {
>             -re " = \($hex\)\r\n$gdb_prompt $" {
>                 set coredump_var_addr($name) $expect_out(1,string)
>             }
>         }
>     }
> }

Thanks for catching this.

This is because of the discussion on:

  <https://sourceware.org/ml/gdb-patches/2015-04/msg00452.html>

And the patch:

  <https://sourceware.org/ml/gdb-patches/2015-04/msg00979.html>

It seems it is not possible to "clear" the variable using "" and then
use as an array.  I think the best way would be to call 'unset
-nocomplain' in this case.  The following patch does this.  With it
applied, the test fully passes on Fedora 20 x86_64 native.

WDYT?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

gdb/testsuite/ChangeLog:
2015-05-07  Sergio Durigan Junior  <sergiodj@redhat.com>

	* gdb.base/coredump-filter.exp: Correctly unset
	"coredump_var_addr" array.

diff --git a/gdb/testsuite/gdb.base/coredump-filter.exp b/gdb/testsuite/gdb.base/coredump-filter.exp
index 72f756a..c601939 100644
--- a/gdb/testsuite/gdb.base/coredump-filter.exp
+++ b/gdb/testsuite/gdb.base/coredump-filter.exp
@@ -170,7 +170,7 @@ gdb_test_multiple "print/x &main" "getting main's address" {
 
 # Obtain the address of each variable that will be checked on each
 # case.
-set coredump_var_addr ""
+unset -nocomplain coredump_var_addr
 foreach item $all_anon_corefiles {
     foreach name [list [lindex $item 3] [lindex $item 4]] {
 	set test "print/x $name"

Re: [PATCH] Fix coredump-filter.exp by correctly unsetting array

[Yao Qi]

Sergio Durigan Junior <sergiodj@redhat.com> writes:

> It seems it is not possible to "clear" the variable using "" and then
> use as an array.  I think the best way would be to call 'unset
> -nocomplain' in this case.  The following patch does this.  With it
> applied, the test fully passes on Fedora 20 x86_64 native.
>
> WDYT?

Your patch is fine by me.

-- 
Yao (齐尧)

Re: [PATCH] Fix coredump-filter.exp by correctly unsetting array

[Sergio Durigan Junior]

On Friday, May 08 2015, Yao Qi wrote:

> Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
>> It seems it is not possible to "clear" the variable using "" and then
>> use as an array.  I think the best way would be to call 'unset
>> -nocomplain' in this case.  The following patch does this.  With it
>> applied, the test fully passes on Fedora 20 x86_64 native.
>>
>> WDYT?
>
> Your patch is fine by me.

Thanks, pushed.

  <https://sourceware.org/ml/gdb-cvs/2015-05/msg00031.html>
  f7797074a5dc314f8922d2e90c1a4ea04b189c36

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Yao Qi]

Luis Machado <lgustavo@codesourcery.com> writes:

> Removing that conditional block i get 14 FAIL's, so it doesn't look
> like this test is suited for usermode QEMU.

I'll leave that block (checking PID) there then...
Patch is pushed in.

-- 
Yao (齐尧)

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Pedro Alves]

On 05/07/2015 03:01 PM, Luis Machado wrote:
> On 05/07/2015 07:44 AM, Luis Machado wrote:
>> On 05/07/2015 06:05 AM, Yao Qi wrote:
>>> Luis Machado <lgustavo@codesourcery.com> writes:
>>>
>>>>>> -# Get the inferior's PID.
>>>>>> -set infpid ""
>>>>>>    gdb_test_multiple "info inferiors" "getting inferior pid" {
>>>>>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>>>>>> -    set infpid $expect_out(1,string)
>>>>>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>>>>>        }
>>>>>>        -re "Remote target.*$gdb_prompt $" {
>>>>>>        # If the target does not provide PID information (like
>>>>>> usermode QEMU),
>>>>>
>>>>> This "If the target does not provide PID information" check sounds
>>>>> odd now.  Do we still need it?
>>>>
>>>> If we're not dealing with PID's, i don't think so.
>>>
>>> At the very start, I removed this block, but I recall that this block is
>>> used as a guard for usermode QEMU which doesn't provide PID
>>> information.  With this patch applied, we'll access
>>> /proc/self/coredump_filter, but I am afraid it doesn't work as expected
>>> on usermode QEMU, because usermode QEMU just intercepts few /proc
>>> accesses and pass most of them through the host linux.  Accessing
>>> /proc/QEMU_PID/coredump_filter isn't what we want in this test, so I
>>> think it's better to skip the test for usermode QEMU.
>>>
>>> Of course, I don't mind removing this block.  Luis, could you try this
>>> patch and remove this block, see whether it causes fails on usermode
>>> QEMU?
>>>
>>
>> Yeah, that sounds problematic. I'll give it a try and will let you know.
> 
> Removing that conditional block i get 14 FAIL's, so it doesn't look like 
> this test is suited for usermode QEMU.

But what does gdb.log show?

With usermode QEMU, the program and qemu are the same process, thus
have the same PID.  I just tried loading up the test's probably (manually
compiled) under F20's qemu-arm, generating a core with gcore, and then
loading the core back into gdb, which worked.

I didn't test beyond that as I don't have a usermode qemu board
file handy (it'd be nice to have one in testsuite/boards/).

I'm not immediately seeing the fundamental reason this shouldn't
have worked, and we may be hiding a bug instead.

Thanks,
Pedro Alves

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Luis Machado]

On 05/08/2015 11:40 AM, Pedro Alves wrote:
> On 05/07/2015 03:01 PM, Luis Machado wrote:
>> On 05/07/2015 07:44 AM, Luis Machado wrote:
>>> On 05/07/2015 06:05 AM, Yao Qi wrote:
>>>> Luis Machado <lgustavo@codesourcery.com> writes:
>>>>
>>>>>>> -# Get the inferior's PID.
>>>>>>> -set infpid ""
>>>>>>>     gdb_test_multiple "info inferiors" "getting inferior pid" {
>>>>>>> -    -re "process \($decimal\).*\r\n$gdb_prompt $" {
>>>>>>> -    set infpid $expect_out(1,string)
>>>>>>> +    -re "process $decimal.*\r\n$gdb_prompt $" {
>>>>>>>         }
>>>>>>>         -re "Remote target.*$gdb_prompt $" {
>>>>>>>         # If the target does not provide PID information (like
>>>>>>> usermode QEMU),
>>>>>>
>>>>>> This "If the target does not provide PID information" check sounds
>>>>>> odd now.  Do we still need it?
>>>>>
>>>>> If we're not dealing with PID's, i don't think so.
>>>>
>>>> At the very start, I removed this block, but I recall that this block is
>>>> used as a guard for usermode QEMU which doesn't provide PID
>>>> information.  With this patch applied, we'll access
>>>> /proc/self/coredump_filter, but I am afraid it doesn't work as expected
>>>> on usermode QEMU, because usermode QEMU just intercepts few /proc
>>>> accesses and pass most of them through the host linux.  Accessing
>>>> /proc/QEMU_PID/coredump_filter isn't what we want in this test, so I
>>>> think it's better to skip the test for usermode QEMU.
>>>>
>>>> Of course, I don't mind removing this block.  Luis, could you try this
>>>> patch and remove this block, see whether it causes fails on usermode
>>>> QEMU?
>>>>
>>>
>>> Yeah, that sounds problematic. I'll give it a try and will let you know.
>>
>> Removing that conditional block i get 14 FAIL's, so it doesn't look like
>> this test is suited for usermode QEMU.
>
> But what does gdb.log show?
>
> With usermode QEMU, the program and qemu are the same process, thus
> have the same PID.  I just tried loading up the test's probably (manually
> compiled) under F20's qemu-arm, generating a core with gcore, and then
> loading the core back into gdb, which worked.
>
> I didn't test beyond that as I don't have a usermode qemu board
> file handy (it'd be nice to have one in testsuite/boards/).
>
> I'm not immediately seeing the fundamental reason this shouldn't
> have worked, and we may be hiding a bug instead.

I'll have it reproduced again and will inspect the log. I recall seeing 
nonsense and random PC addresses that didn't point to proper symbols.

Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code

[Sergio Durigan Junior]

On Wednesday, May 06 2015, Pedro Alves wrote:

>> 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.
>
> Probably the right fix would be for dejagnu to put ''s around
> the whole sh -c command in rsh_exec:
>
>     set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout]
>
> dunno if that would work with real rsh.  Alternatively, teach
> dejagnu about a real ssh mode...

FWIW, I managed to solve the problem by hacking
/usr/share/dejagnu/rsh.exp:rsh_exec and doing:

  set ret [local_exec "$RSH $rsh_useropts $hostname \"sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'\"" $inp $outp $timeout]

Then I found this message by Pedro.

But only doing this is not enough: because of the quote-hell, the
coredump-filter.exp needs to be adjusted to:

  remote_exec target "echo $filter_flag > /proc/$ipid/coredump_filter"

I.e., remove the "sh -c" and the extra quotes.  After that, everything
passes.

Since the full solution involves hacking dejagnu, then I agree that a
most desirable solution is to hack the C source file as Yao did.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/