From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10304291606.AA20558@clio.rice.edu>
Subject: Re: uclock proposed patch
To: djgpp-workers AT delorie DOT com
Date: Tue, 29 Apr 2003 11:06:16 -0500 (CDT)
In-Reply-To: <3EAE64CC.DBA5C7D7@phekda.freeserve.co.uk> from "Richard Dawe" at Apr 29, 2003 12:41:00 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > +  short *eip = (short *)__djgpp_exception_state->__eip;
> > +  if(*eip == 0x310f) {
> 
> Presumably this is the opcode for the RDTSC instruction?

Yes, worth a comment.

> Perhaps we could try executing _rdtsc after calling signal, to see if we
> actually need the signal handler? If not, restore the previous handler.

I agree (thought about that last night after going to bed).

> I don't like the idea of installing the signal handler, if we don't need it. I
> suppose this would have the disadvantage that the code will behave differently
> on systems with and without RDTSC. That may be a problem, if no-one tests it
> on a system without RDTSC. I certainly don't have any systems without RDTSC.
> So maybe it would be best to always install it.

I decided it would be best to temporarily install it, see if it works,
and if so remove the handler and use it.  If not, then don't call rdtsc.
But if rdtsc isn't available, I can either just make the high precision
bits all zero, or skip to the PIT code.  (Which is better, flakey 
high precision, or no high precision?  Currently we do flakey ...)

> What happens if we get SIGILL, but the instruction was not RDTSC?

We return instead of longjmp()'ing, which just causes the standard traceback.

> I agree with Gisle that we should save and chain any previous SIGILL handler
> here.

Save/restore - OK.  Chain is overkill

> Do you plan to update the documentation? 

Of course (and wc204..).  But I'd rather write the code 3 times and 
docs once, instead of each 3 times :-)

> If so, maybe we should mention the fact we add a handler for SIGILL. 
> A user program will need to chain SIGILL, if
> they install a SIGILL handler after calling uclock.

I'll document it installs a temporary handler and restores it.  But then
the user shouldn't be concerned unless they have installed a handler
and done something they expect the library code to generate some
additional unexpected SIGILL in about 10 lines of code...

> Where is th the _rdtsc function/macro defined?

it's in time.h - it's either a inline function or a real function 
when compiled without optimization.  I added it several months ago;
it's quite useful for other things too.  The texinfo docs for _rdtsc
contain the same code fragment as an example for protecting it's usage.