Re: [PATCH 07/10] Add __pthread_set_abort_hook export

[Andi Kleen <andi at firstfloor dot org>]

On Fri, Jan 25, 2013 at 06:45:18PM +0100, Torvald Riegel wrote:
> > > (2) For explicitly transactional code (ie, code in which some programmer
> > > explicitly used TSX), you want a facility to communicate some
> > > information out of transactions without having to finish execution of
> > > these transactions.
> > 
> > I want it for all transactional code, both implicit and explicit.
> 
> In that case, wouldn't it be better to have something that is robust
> enough so that we can put it into assert()?  Otherwise, if you have
> existing implicitly transactional code, you couldn't use the assertions
> it might contain, and would have to rewrite them to use TXN_ASSERT
> instead.

Hmm yes we could add this to __assert_fail

if (cpu_has_rtm) { 
	while (_xtest())
		_xend();
}

It won't work for HLE though, but that's no different from the abort
hook. The _xend() would abort in HLE, so you won't get an assert, but 
at least the program won't crash and just reexecute.

Sounds ok for me. With that I would be ok with dropping the hook.

There was one more use case with debugger break points on abort, but those
could be likely solved differently too.

> > > in, or does TSX not complain about replacing xrelease with an RTM
> > > commit?
> > 
> > RTM inside HLE aborts.
> 
> And as you said, HLE inside RTM txns aborts too, which means that
> whenever we could get something out with an abort, we could also commit
> the txn early (ie, with the simple loop I suggested).  Or not?

To commit HLE you need to know the lock address, lock size and lock value.
I don't see any generic way to get that in a assert.

Maybe I misunderstood your questions?

However at least the glibc doesn't use HLE, so for this pthread
implementation it's academic.
 
> > > 
> > > If TSX complains, we get a fault, IIRC, so when this fault happened
> > > within the code with the loop above, we'd still know that some assertion
> > > fired.  If we inline this code, or add other hints regarding what called
> > > it, I guess we could find out which assertion triggered the fault by
> > > looking at the code around where the fault happened?  Thoughts?
> > 
> > Inline the only way to know the code is to use XABORT and encode 
> > it in the abort code.
> 
> Do you mean to that the fault will not reveal the real address but just
> the xbegin instruction's addr?  Forgot about this one...

I'm not sure what you mean with "fault". abort? 

All exceptions inside the transaction lead to an abort.

The program doesn't know the abort address normally, the only way to get
addresses is to use perf to look at the PEBS record and/or the LBRs.
In theory you can do self monitoring with perf, but I suspect in most
cases it will be only used with external profiling tools.

> > while (_xtest()) _xend(): assert() may work.
> 
> So let's try this instead.
> 
> It would be nice if we could get this into assert_fail (if I remember
> the name correctly), but I'm not very optimistic that we can do this in
> a robust way given all this relies on (e.g, no RTM inside HLE etc.)

I think it should work. With HLE it would just abort, just the same
as the syscall in the __assert_fail would. With RTM it would commit.
The two cannot be nested.

-Andi