This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code
- From: Pedro Alves <palves at redhat dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 08 May 2015 15:40:08 +0100
- Subject: Re: [rfc] Fix PR 18208: update /proc/pid/coredump_filter by c code
- Authentication-results: sourceware.org; auth=none
- References: <1429889336-12277-1-git-send-email-qiyaoltc at gmail dot com> <554A3D61 dot 8090302 at redhat dot com> <554A44B9 dot 3090503 at codesourcery dot com> <86sib8vjtv dot fsf at gmail dot com> <554B4223 dot 1000003 at codesourcery dot com> <554B702F dot 5090006 at codesourcery dot 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