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

[Luis Machado <lgustavo@codesourcery.com>]

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.