Re: [V6,1/9] elf: Add new powerpc specifc core note sections
From: Michael Neuling
Date: Wed Mar 18 2015 - 18:45:13 EST
On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> Michael Neuling <mikey@xxxxxxxxxxx> wrote on 23.02.2015 05:51:50:
>
> > Sorry for the slow response.
>
> Same here :-(
I'm going to break the cycle and respond in a few hours :-)
> > 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 stack
> > pointer of the checkpointed registers.
>
> 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
> the transaction is doomed, but we can still *inspect* it in GDB after
> 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.)
>
> I guess we could use the minimum of transactional and checkpointed r1
> in that case, to be safe either way.
Sounds good.
<snip>
> > > 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
> > > state (suspended), while leaving information about the interrupted
> > > transaction visible.
> > >
> > > 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 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
> > > we're now in nontransactional state, and there is probably no way
> > > to force us back into transactional/suspended state ...).
> >
> > Yep.
>
> 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.
>
> > Getting back to the kernel interface, are you happy with what Anshuman
> > has proposed in the current series?
>
> Given the discussion above, this seems fine to me now.
Great, we'll push through with this in mind.
Thanks!
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/