From owner-cvs-all  Sun Feb 25  1:28:49 2001
Delivered-To: cvs-all@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2997337B491; Sun, 25 Feb 2001 01:28:42 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA00217;
	Sun, 25 Feb 2001 20:28:17 +1100
Date: Sun, 25 Feb 2001 20:23:32 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: Peter Wemm <peter@netplex.com.au>
Cc: Jake Burkholder <jake@FreeBSD.org>, cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/i386/i386 db_trace.c exception.s machdep.c
 trap.c src/sys/i386/include asnames.h 
In-Reply-To: <200102250736.f1P7aVi01775@mobile.wemm.org>
Message-ID: <Pine.BSF.4.21.0102251955220.6715-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, 24 Feb 2001, Peter Wemm wrote:

> Bruce Evans wrote:
> > On Sat, 24 Feb 2001, Jake Burkholder wrote:
> > >   - Rename the lcall system call handler from Xsyscall to Xlcall_syscall
> > >     to be more like Xint0x80_syscall and less like c function syscall().
> > 
> > This is sort of backwards.  Xsyscall is supposed to be named like the C
> > function syscall(), but it should be used for normal int 0x80 syscalls.
> 
> Well, given that we have two, "Xsyscall" was wrong as it implies that it
> was the "normal" one (it is not).  Would you rather that Xint0x80syscall
> be renamed to Xsyscall instead?

Yes.

> > >   - Reduce code duplication between the int0x80 and lcall handlers by
> > >     shuffling the elfags into the right place, saving the sizeof the
> > >     instruction in tf_err and jumping into the common int0x80 code.
> > 
> > This breaks profiling and pessimizes Xsyscall a little.  Please back this
> > out.
> 
> Are you sure? The X*syscall stubs dont seem to be profiled..

Yes.  The FAKE_MCOUNT stuff does it.

> 
> #define IDTVEC(name)    ALIGN_TEXT; .globl __CONCAT(X,name); \
>                         .type __CONCAT(X,name),@function; __CONCAT(X,name):
> 
>         SUPERALIGN_TEXT
> IDTVEC(int0x80_syscall)
>         pushl   $2                      /* sizeof "int 0x80" */
> syscall_with_err_pushed:
>         subl    $4,%esp                 /* skip over tf_trapno */
>         pushal
>         pushl   %ds
>         pushl   %es
>         pushl   %fs
>         mov     $KDSEL,%ax              /* switch to kernel segments */
>         mov     %ax,%ds
>         mov     %ax,%es
>         mov     $KPSEL,%ax
>         mov     %ax,%fs
>         FAKE_MCOUNT(13*4(%esp))
>         call    syscall
>         MEXITCOUNT
>         jmp     doreti
> 
> Obviously I could easily be misunderstanding things, but the FAKE_MCOUNT
> pulls the caller off the stack, right?  How does this all tie in?
> Would this change imply that the cpu time of the lcall version would be
> applied to the int0x80 version?

It's fairly complicated.  The call to mcount must be delayed until
enough registers are saved and enough of the frame is set up.  Since
we jump before doing any mcount stuff, the Xlcall_syscall will be
merged with Xint0x80_syscall as far as mcount can see.  The frame is
uniform (I hope), so 13*4(%esp) gives the correct syscaller's address
for both cases; only the address of mcount's caller is messed up.
For low resolution profiling, tick counters are updated indpendently
and will be reported by gprof as "<spontaneous>" activity in
Xlcall_syscall.  For high resolution profiling, timestamps are read
by mcount, so all activity for Xlcall_syscall will be counted as for
Xint0x80_syscall.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message