This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]