diff for duplicates of <1426719027.4866.4.camel@neuling.org> diff --git a/a/1.txt b/N1/1.txt index f505aa5..1887943 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,21 +1,19 @@ On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote: > On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote: > > Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50: -> >=20 +> > > > > Sorry for the slow response. -> >=20 +> > > > Same here :-( ->=20 +> > I'm going to break the cycle and respond in a few hours :-) ->=20 ->=20 +> +> > > > I think what you're proposing with running the inferior function in -> > > suspend mode may end up corrupting the stack in this way. You'd need= - to -> > > be really careful to make sure the inferior function is run on the st= -ack +> > > suspend mode may end up corrupting the stack in this way. You'd need to +> > > be really careful to make sure the inferior function is run on the stack > > > pointer of the checkpointed registers. -> >=20 +> > > > On the other hand, if code called a subroutine after the tbegin, if we > > were using the checkpointed r1, this might corrupt the stack of the > > transactional code. (This code will never actually *run* again since @@ -23,14 +21,14 @@ ack > > the inferior call has returned, so the stack should remain unchanged. > > Well .. if the transaction is suspended, the code might in fact still > > run, so it should remain unchanged either way.) -> >=20 +> > > > I guess we could use the minimum of transactional and checkpointed r1 > > in that case, to be safe either way. ->=20 +> > Sounds good. ->=20 +> > <snip> ->=20 +> > > > > Using the combination of (A)+(A') would be easiest to implement > > > > in GDB without modifying a lot of common code, and would have the > > > > advantage that the inferior function always executes in the same @@ -39,8 +37,7 @@ ack > > > > > > > > Using the combination of (B)+(B') would be a bit more difficult > > > > to implement (but certainly feasible), and would have the advantage -> > > > that the inferior function always executes in nontransactional stat= -e +> > > > that the inferior function always executes in nontransactional state > > > > (which is what it would most likely expect, anyway). However, the > > > > disadvantage is that after the inferior call returns, GDB is unable > > > > to fully restore the visible inferior state as it was before (since @@ -48,23 +45,22 @@ e > > > > to force us back into transactional/suspended state ...). > > > > > > Yep. -> >=20 +> > > > So right now I'd tend to prefer (A)+(A'), but the important thing is > > that the kernel seems to provide all features required for GDB to > > implement any of the above, so we can still make that decision later. -> >=20 -> > > Getting back to the kernel interface, are you happy with what Anshuma= -n +> > +> > > Getting back to the kernel interface, are you happy with what Anshuman > > > has proposed in the current series? -> >=20 +> > > > Given the discussion above, this seems fine to me now. ->=20 +> > Great, we'll push through with this in mind. Anshuman, 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. =20 +find anything like that in this patch set. Mikey diff --git a/a/content_digest b/N1/content_digest index 7961098..d33ca5e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,45 +16,44 @@ "Date\0Thu, 19 Mar 2015 09:50:27 +1100\0" "To\0Ulrich Weigand <Ulrich.Weigand@de.ibm.com>" " Anshuman Khandual <khandual@linux.vnet.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 Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:\n" "> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:\n" "> > Michael Neuling <mikey@neuling.org> wrote on 23.02.2015 05:51:50:\n" - "> >=20\n" + "> > \n" "> > > Sorry for the slow response.\n" - "> >=20\n" + "> > \n" "> > Same here :-(\n" - ">=20\n" + "> \n" "> I'm going to break the cycle and respond in a few hours :-)\n" - ">=20\n" - ">=20\n" + "> \n" + "> \n" "> > > I think what you're proposing with running the inferior function in\n" - "> > > suspend mode may end up corrupting the stack in this way. You'd need=\n" - " to\n" - "> > > be really careful to make sure the inferior function is run on the st=\n" - "ack\n" + "> > > suspend mode may end up corrupting the stack in this way. You'd need to\n" + "> > > be really careful to make sure the inferior function is run on the stack\n" "> > > pointer of the checkpointed registers.\n" - "> >=20\n" + "> > \n" "> > On the other hand, if code called a subroutine after the tbegin, if we\n" "> > were using the checkpointed r1, this might corrupt the stack of the\n" "> > transactional code. (This code will never actually *run* again since\n" @@ -62,14 +61,14 @@ "> > the inferior call has returned, so the stack should remain unchanged.\n" "> > Well .. if the transaction is suspended, the code might in fact still\n" "> > run, so it should remain unchanged either way.)\n" - "> >=20\n" + "> > \n" "> > I guess we could use the minimum of transactional and checkpointed r1\n" "> > in that case, to be safe either way.\n" - ">=20\n" + "> \n" "> Sounds good.\n" - ">=20\n" + "> \n" "> <snip>\n" - ">=20\n" + "> \n" "> > > > Using the combination of (A)+(A') would be easiest to implement\n" "> > > > in GDB without modifying a lot of common code, and would have the\n" "> > > > advantage that the inferior function always executes in the same\n" @@ -78,8 +77,7 @@ "> > > >\n" "> > > > Using the combination of (B)+(B') would be a bit more difficult\n" "> > > > to implement (but certainly feasible), and would have the advantage\n" - "> > > > that the inferior function always executes in nontransactional stat=\n" - "e\n" + "> > > > that the inferior function always executes in nontransactional state\n" "> > > > (which is what it would most likely expect, anyway). However, the\n" "> > > > disadvantage is that after the inferior call returns, GDB is unable\n" "> > > > to fully restore the visible inferior state as it was before (since\n" @@ -87,25 +85,24 @@ "> > > > to force us back into transactional/suspended state ...).\n" "> > >\n" "> > > Yep.\n" - "> >=20\n" + "> > \n" "> > So right now I'd tend to prefer (A)+(A'), but the important thing is\n" "> > that the kernel seems to provide all features required for GDB to\n" "> > implement any of the above, so we can still make that decision later.\n" - "> >=20\n" - "> > > Getting back to the kernel interface, are you happy with what Anshuma=\n" - "n\n" + "> > \n" + "> > > Getting back to the kernel interface, are you happy with what Anshuman\n" "> > > has proposed in the current series?\n" - "> >=20\n" + "> > \n" "> > Given the discussion above, this seems fine to me now.\n" - ">=20\n" + "> \n" "> Great, we'll push through with this in mind.\n" "\n" "Anshuman,\n" "\n" "With that in mind, do we have a way to set the top 32bits of the MSR\n" "(which contain the TM bits) when ptracing 32 bit processes? I can't\n" - "find anything like that in this patch set. =20\n" + "find anything like that in this patch set. \n" "\n" Mikey -a9909bdbd2a818d5c065ca72b1855e9b508ae12a17dad23616091e25840c014b +a9e30eebd2ffae4fb221770bdf0cfdc089577339a7126db32554734398b79def
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.