diff for duplicates of <1422419289.9646.20.camel@neuling.org> diff --git a/a/1.txt b/N1/1.txt index d7ee528..225107a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,46 +2,42 @@ On Fri, 2015-01-23 at 08:44 +1100, Michael Neuling wrote: > > > > Inside transaction both running and check pointed values can be > > > > probed independently. > > > -> > > Yep, that's the idea, although setting the running values won't chang= -e -> > > anything since the the translation is already doomed and will abort o= -nce +> > > Yep, that's the idea, although setting the running values won't change +> > > anything since the the translation is already doomed and will abort once > > > the cpu starts executing it. -> >=20 +> > > > So this looks to me like the overall effect on debugging transactional > > code should be the same on Power and z, even if some internal details > > are different (on z, the exception will automatically abort the -> > transaction; on p, the exception itself will not abort, but *restarting= -* +> > transaction; on p, the exception itself will not abort, but *restarting* > > user space execution will). ->=20 +> > Yep ->=20 +> > > From a GDB perspective, it would therefore be preferable if the ptrace > > interface were to behave in a similar fashion on p as on z: that is, -> > if an exception interrupting a transaction results in a ptrace intercep= -t, +> > if an exception interrupting a transaction results in a ptrace intercept, > > at this point: ->=20 +> > Agreed. ->=20 +> > > - the "normal" ptrace register set commands should access the > > *checkpointed* registers (allowing both read and write access) ->=20 +> > OK, this is a change from what we've been proposing with Anshuman's > patch set but I'm happy to change it to make it consistent with other > architectures. It's relatively arbitrary which goes where, so I'm happy > to change. ->=20 +> > > -- GDB will use this to display current position (already reflecting > > the fact that the transaction will abort), and use it when changing > > register values e.g. to effect an inferior function call ->=20 +> > "Current position" depends on your perspective. Is it the last executed > instruction or the next executed instruction? If it's the last executed > instruction, then it's the running values. If it's the next, then it's -> the check pointed. =20 ->=20 +> the check pointed. +> > Anyway, I'm happy to make it the check pointed values for the sake of > ptrace/gdb. @@ -54,10 +50,10 @@ It makes sense for normal transactions but for user suspended transactions the running values are the ones you want to modify since that is where you'll end up restarting from. The hardware will only abort/rollback once a tresume is encountered. - *=20 + * So we could do what you're talking about for normal transactions and then switch them for suspended transactions. But this just seems to be -making the kernel interface overly complicated. =20 +making the kernel interface overly complicated. So I'm keen on just keeping it the way Anshuman has now and GDB has to understand the program flow better to know which ones it wants to @@ -67,8 +63,8 @@ what it wants to modify. > > - a new ptrace register set should allow access (read-only) to the > > *running* register values ->=20 -> This is because changing them won't ever result in a side effect? =20 +> +> This is because changing them won't ever result in a side effect? For the same reason as above, we need to be able to modify the running values when it's a user suspended transaction. So I don't agree with diff --git a/a/content_digest b/N1/content_digest index 32798b7..ce2f2e9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,71 +10,68 @@ "Subject\0Re: [V6,1/9] elf: Add new powerpc specifc core note sections\0" "Date\0Wed, 28 Jan 2015 15:28:09 +1100\0" "To\0Ulrich Weigand <Ulrich.Weigand@de.ibm.com>\0" - "Cc\0shuahkh@osg.samsung.com" - james.hogan@imgtec.com + "Cc\0akpm@linux-foundation.org" avagin@openvz.org - Paul.Clothier@imgtec.com - peterz@infradead.org - linux-kernel@vger.kernel.org + davej@redhat.com davem@davemloft.net dhowells@redhat.com - linuxppc-dev@ozlabs.org + Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> + james.hogan@imgtec.com + Anshuman Khandual <khandual@linux.vnet.ibm.com> kirjanov@gmail.com - tglx@linutronix.de + linux-kernel@vger.kernel.org + linuxppc-dev@ozlabs.org + Michael Ellerman <mpe@ellerman.id.au> oleg@redhat.com - sukadev@linux.vnet.ibm.com - davej@redhat.com - akpm@linux-foundation.org palves@redhat.com - Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com> + Paul.Clothier@imgtec.com + peterz@infradead.org sam.bobroff@au1.ibm.com - " Anshuman Khandual <khandual@linux.vnet.ibm.com>\0" + shuahkh@osg.samsung.com + sukadev@linux.vnet.ibm.com + " tglx@linutronix.de\0" "\00:1\0" "b\0" "On Fri, 2015-01-23 at 08:44 +1100, Michael Neuling wrote:\n" "> > > > Inside transaction both running and check pointed values can be\n" "> > > > probed independently.\n" "> > >\n" - "> > > Yep, that's the idea, although setting the running values won't chang=\n" - "e\n" - "> > > anything since the the translation is already doomed and will abort o=\n" - "nce\n" + "> > > Yep, that's the idea, although setting the running values won't change\n" + "> > > anything since the the translation is already doomed and will abort once\n" "> > > the cpu starts executing it.\n" - "> >=20\n" + "> > \n" "> > So this looks to me like the overall effect on debugging transactional\n" "> > code should be the same on Power and z, even if some internal details\n" "> > are different (on z, the exception will automatically abort the\n" - "> > transaction; on p, the exception itself will not abort, but *restarting=\n" - "*\n" + "> > transaction; on p, the exception itself will not abort, but *restarting*\n" "> > user space execution will).\n" - ">=20\n" + "> \n" "> Yep\n" - ">=20\n" + "> \n" "> > From a GDB perspective, it would therefore be preferable if the ptrace\n" "> > interface were to behave in a similar fashion on p as on z: that is,\n" - "> > if an exception interrupting a transaction results in a ptrace intercep=\n" - "t,\n" + "> > if an exception interrupting a transaction results in a ptrace intercept,\n" "> > at this point:\n" - ">=20\n" + "> \n" "> Agreed.\n" - ">=20\n" + "> \n" "> > - the \"normal\" ptrace register set commands should access the\n" "> > *checkpointed* registers (allowing both read and write access)\n" - ">=20\n" + "> \n" "> OK, this is a change from what we've been proposing with Anshuman's\n" "> patch set but I'm happy to change it to make it consistent with other\n" "> architectures. It's relatively arbitrary which goes where, so I'm happy\n" "> to change.\n" - ">=20\n" + "> \n" "> > -- GDB will use this to display current position (already reflecting\n" "> > the fact that the transaction will abort), and use it when changing\n" "> > register values e.g. to effect an inferior function call\n" - ">=20\n" + "> \n" "> \"Current position\" depends on your perspective. Is it the last executed\n" "> instruction or the next executed instruction? If it's the last executed\n" "> instruction, then it's the running values. If it's the next, then it's\n" - "> the check pointed. =20\n" - ">=20\n" + "> the check pointed. \n" + "> \n" "> Anyway, I'm happy to make it the check pointed values for the sake of\n" "> ptrace/gdb.\n" "\n" @@ -87,10 +84,10 @@ "transactions the running values are the ones you want to modify since\n" "that is where you'll end up restarting from. The hardware will only\n" "abort/rollback once a tresume is encountered.\n" - " *=20\n" + " * \n" "So we could do what you're talking about for normal transactions and\n" "then switch them for suspended transactions. But this just seems to be\n" - "making the kernel interface overly complicated. =20\n" + "making the kernel interface overly complicated. \n" "\n" "So I'm keen on just keeping it the way Anshuman has now and GDB has to\n" "understand the program flow better to know which ones it wants to\n" @@ -100,8 +97,8 @@ "\n" "> > - a new ptrace register set should allow access (read-only) to the\n" "> > *running* register values\n" - ">=20\n" - "> This is because changing them won't ever result in a side effect? =20\n" + "> \n" + "> This is because changing them won't ever result in a side effect? \n" "\n" "For the same reason as above, we need to be able to modify the running\n" "values when it's a user suspended transaction. So I don't agree with\n" @@ -110,4 +107,4 @@ "\n" Mikey -cfcb9abc51fca896e29eb985200a6417087f1abe32918bf30ced66882c4f03ac +02e3ec4cf7eed0306e072f1d41403a80fa918f6d122db9a253247370d992cf71
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.