All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Michael Neuling <mikey@neuling.org>
Cc: james.hogan@imgtec.com, avagin@openvz.org,
	Paul.Clothier@imgtec.com, linuxppc-dev@ozlabs.org,
	peterz@infradead.org, palves@redhat.com, davem@davemloft.net,
	shuahkh@osg.samsung.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, dhowells@redhat.com,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	kirjanov@gmail.com, oleg@redhat.com, davej@redhat.com,
	tglx@linutronix.de, sukadev@linux.vnet.ibm.com,
	Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>,
	sam.bobroff@au1.ibm.com
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections
Date: Fri, 10 Apr 2015 14:40:35 +0530	[thread overview]
Message-ID: <5527938B.1030901@linux.vnet.ibm.com> (raw)
In-Reply-To: <1428635033.1554.49.camel@neuling.org>

On 04/10/2015 08:33 AM, Michael Neuling wrote:
> On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
>> On 04/09/2015 04:41 AM, Michael Neuling wrote:
>>> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>>>> 11:34:30:
>>>>
>>>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>>>> (which contain the TM bits) when ptracing 32 bit processes?  I can't
>>>>>> find anything like that in this patch set.
>>>>>
>>>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>>>> adding in the patch series or we can create one more separate ELF core
>>>>> note for that purpose. Let me know your opinion on this.
>>>>
>>>> I'm not sure I understand this.  I thought we had the following:
>>>>
>>>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>>>>   built on all current Linux distributions), then PTRACE_GETREGS etc.
>>>>   will *always* operate on 64-bit register sets, even if the target
>>>>   process is 32-bit.
>>>>
>>>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>>>>   operate on 32-bit register sets.   However, there is a separate
>>>>   PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>>>>   the opportunity to operate on the full 64-bit register set.  Both
>>>>   apply independently of whether the target process is 32-bit or
>>>>   64-bit.
>>>>
>>>> Is this not correct?
>>>
>>> I think you're correct.  We should be right.  I'd forgotten about the
>>> GET/SETREGS64 interfaces.
>>
>> In that case, is the patch series complete and okay ? Is there any thing
>> else we need to verify other than waiting for the GDB test results which
>> Edjunior has been working on. But I am not aware of the status on the GDB
>> test development front.
> 
> I think we are good.

I had posted a newer version [V7] of this patch series couple of months back
which got ignored while the discussion continued in this version.

V7: https://lkml.org/lkml/2015/1/14/19

Apart from the last gitignore related patch which already got merged into
mainline separately, all other patches should be as good even today. I will
try rebasing the series, running the base tests again and re post it in some
time.


WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Michael Neuling <mikey@neuling.org>
Cc: james.hogan@imgtec.com, avagin@openvz.org,
	Paul.Clothier@imgtec.com,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	peterz@infradead.org, palves@redhat.com,
	Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>,
	shuahkh@osg.samsung.com, linux-kernel@vger.kernel.org,
	dhowells@redhat.com, linuxppc-dev@ozlabs.org, kirjanov@gmail.com,
	tglx@linutronix.de, oleg@redhat.com, davej@redhat.com,
	akpm@linux-foundation.org, sukadev@linux.vnet.ibm.com,
	davem@davemloft.net, sam.bobroff@au1.ibm.com
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections
Date: Fri, 10 Apr 2015 14:40:35 +0530	[thread overview]
Message-ID: <5527938B.1030901@linux.vnet.ibm.com> (raw)
In-Reply-To: <1428635033.1554.49.camel@neuling.org>

On 04/10/2015 08:33 AM, Michael Neuling wrote:
> On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:
>> On 04/09/2015 04:41 AM, Michael Neuling wrote:
>>> On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:
>>>> Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote on 23.03.2015
>>>> 11:34:30:
>>>>
>>>>>> With that in mind, do we have a way to set the top 32bits of the MSR
>>>>>> (which contain the TM bits) when ptracing 32 bit processes?  I can't
>>>>>> find anything like that in this patch set.
>>>>>
>>>>> No, we dont have that yet. When ptracing in 32-bit mode the MSR value
>>>>> which can be viewed or set from the user space through PTRACE_GETREGS
>>>>> PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
>>>>> the upper 32 bits of MSR as part of one of the ELF core notes we are
>>>>> adding in the patch series or we can create one more separate ELF core
>>>>> note for that purpose. Let me know your opinion on this.
>>>>
>>>> I'm not sure I understand this.  I thought we had the following:
>>>>
>>>> - If the process calling ptrace is itself 64-bit (which is how GDB is
>>>>   built on all current Linux distributions), then PTRACE_GETREGS etc.
>>>>   will *always* operate on 64-bit register sets, even if the target
>>>>   process is 32-bit.
>>>>
>>>> - If the process calling ptrace is 32-bit, then PTRACE_GETREGS will
>>>>   operate on 32-bit register sets.   However, there is a separate
>>>>   PTRACE_GETREGS64 / PTRACE_SETREGS64 call that will also provide
>>>>   the opportunity to operate on the full 64-bit register set.  Both
>>>>   apply independently of whether the target process is 32-bit or
>>>>   64-bit.
>>>>
>>>> Is this not correct?
>>>
>>> I think you're correct.  We should be right.  I'd forgotten about the
>>> GET/SETREGS64 interfaces.
>>
>> In that case, is the patch series complete and okay ? Is there any thing
>> else we need to verify other than waiting for the GDB test results which
>> Edjunior has been working on. But I am not aware of the status on the GDB
>> test development front.
> 
> I think we are good.

I had posted a newer version [V7] of this patch series couple of months back
which got ignored while the discussion continued in this version.

V7: https://lkml.org/lkml/2015/1/14/19

Apart from the last gitignore related patch which already got merged into
mainline separately, all other patches should be as good even today. I will
try rebasing the series, running the base tests again and re post it in some
time.

  reply	other threads:[~2015-04-10  9:10 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-02  7:56 [PATCH V6 0/9] Add new powerpc specific ELF core notes Anshuman Khandual
2014-12-02  7:56 ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 1/9] elf: Add new powerpc specifc core note sections Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-03  5:22   ` [V6,1/9] " Michael Ellerman
2014-12-03  5:22     ` Michael Ellerman
2014-12-03  6:48     ` Anshuman Khandual
2014-12-03  6:48       ` Anshuman Khandual
2014-12-08 10:08       ` Anshuman Khandual
2014-12-08 10:08         ` Anshuman Khandual
2014-12-19 19:28         ` Edjunior Barbosa Machado
2014-12-19 19:28           ` Edjunior Barbosa Machado
2015-01-01  8:08           ` Anshuman Khandual
2015-01-01  8:08             ` Anshuman Khandual
2015-01-14  4:44             ` Anshuman Khandual
2015-01-14  4:44               ` Anshuman Khandual
2015-01-21 23:39             ` Michael Neuling
2015-01-21 23:39               ` Michael Neuling
2015-01-22 15:55               ` Ulrich Weigand
2015-01-22 15:55                 ` Ulrich Weigand
2015-01-22 21:44                 ` Michael Neuling
2015-01-22 21:44                   ` Michael Neuling
2015-01-28  4:28                   ` Michael Neuling
2015-01-28  4:28                     ` Michael Neuling
2015-02-06 14:47                     ` Ulrich Weigand
2015-02-06 14:47                       ` Ulrich Weigand
2015-02-23  4:51                       ` Michael Neuling
2015-02-23  4:51                         ` Michael Neuling
2015-03-18 12:53                         ` Ulrich Weigand
2015-03-18 12:53                           ` Ulrich Weigand
2015-03-18 22:45                           ` Michael Neuling
2015-03-18 22:45                             ` Michael Neuling
2015-03-18 22:50                             ` Michael Neuling
2015-03-18 22:50                               ` Michael Neuling
2015-03-23 10:34                               ` Anshuman Khandual
2015-03-23 10:34                                 ` Anshuman Khandual
2015-04-08 17:50                                 ` Ulrich Weigand
2015-04-08 17:50                                   ` Ulrich Weigand
2015-04-08 23:11                                   ` Michael Neuling
2015-04-08 23:11                                     ` Michael Neuling
2015-04-09 12:50                                     ` Anshuman Khandual
2015-04-09 12:50                                       ` Anshuman Khandual
2015-04-10  3:03                                       ` Michael Neuling
2015-04-10  3:03                                         ` Michael Neuling
2015-04-10  9:10                                         ` Anshuman Khandual [this message]
2015-04-10  9:10                                           ` Anshuman Khandual
2015-04-10 10:33                                           ` Ulrich Weigand
2015-04-10 10:33                                             ` Ulrich Weigand
2015-04-13  8:48                                             ` Anshuman Khandual
2015-04-13  8:48                                               ` Anshuman Khandual
2015-04-20  6:42                                               ` Anshuman Khandual
2015-04-20  6:42                                                 ` Anshuman Khandual
2015-04-20 12:27                                               ` Ulrich Weigand
2015-04-20 12:27                                                 ` Ulrich Weigand
2015-04-21  4:55                                                 ` Anshuman Khandual
2015-04-21  4:55                                                   ` Anshuman Khandual
2015-04-21 14:41                                                   ` Ulrich Weigand
2015-04-21 14:41                                                     ` Ulrich Weigand
2015-04-22  9:24                                                     ` Anshuman Khandual
2015-04-22  9:24                                                       ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 2/9] powerpc, process: Add the function flush_tmregs_to_thread Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 3/9] powerpc, ptrace: Enable fpr_(get/set) for transactional memory Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 4/9] powerpc, ptrace: Enable vr_(get/set) " Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 5/9] powerpc, ptrace: Enable support for transactional memory register sets Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 6/9] powerpc, ptrace: Enable support for miscellaneous debug registers Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 7/9] selftests, powerpc: Add test case for TM related ptrace interface Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 8/9] selftests, powerpc: Make GIT ignore all binaries related to TM Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02  7:56 ` [PATCH V6 9/9] selftests: Make GIT ignore all binaries in powerpc test suite Anshuman Khandual
2014-12-02  7:56   ` Anshuman Khandual
2014-12-02 18:23   ` Shuah Khan
2014-12-02 18:23     ` Shuah Khan
2014-12-03  5:46     ` Anshuman Khandual
2014-12-03  5:46       ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5527938B.1030901@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=Paul.Clothier@imgtec.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=davej@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=emachado@linux.vnet.ibm.com \
    --cc=james.hogan@imgtec.com \
    --cc=kirjanov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=oleg@redhat.com \
    --cc=palves@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sam.bobroff@au1.ibm.com \
    --cc=shuahkh@osg.samsung.com \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.