Re: [V6,1/9] elf: Add new powerpc specifc core note sections

[Michael Neuling <mikey@neuling.org>]

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 :-(

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 t=
o
> > be really careful to make sure the inferior function is run on the stac=
k
> > 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
> 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.)
>=20
> 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.
>=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 Anshuman
> > has proposed in the current series?
>=20
> Given the discussion above, this seems fine to me now.

Great, we'll push through with this in mind.

Thanks!
Mikey