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

[Pedro Alves <palves@redhat.com>]

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