On Thu, 2015-04-09 at 18:20 +0530, Anshuman Khandual wrote:

On 04/09/2015 04:41 AM, Michael Neuling wrote:

quoted

On Wed, 2015-04-08 at 19:50 +0200, Ulrich Weigand wrote:

quoted

Anshuman Khandual [off-list ref] wrote on 23.03.2015
11:34:30:

quoted

quoted

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 cor=

e

quoted

quoted

quoted

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?

=20
I think you're correct.  We should be right.  I'd forgotten about the
GET/SETREGS64 interfaces.

=20
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.

Mikey

=20
Edjunior,
=20
Do you have any updates ?
=20
Regards
Anshuman
=20
=20