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


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