From owner-freebsd-alpha Tue Dec 18 11: 3: 8 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by hub.freebsd.org (Postfix) with ESMTP id 7907837B416 for ; Tue, 18 Dec 2001 11:03:04 -0800 (PST) Received: (qmail 6611 invoked from network); 18 Dec 2001 19:03:02 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Dec 2001 19:03:02 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <15391.37056.22312.225550@grasshopper.cs.duke.edu> Date: Tue, 18 Dec 2001 11:02:48 -0800 (PST) From: John Baldwin To: Andrew Gallatin Subject: Re: mdproc flags in KSE Cc: alpha@FreeBSD.ORG Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 18-Dec-01 Andrew Gallatin wrote: > > John Baldwin writes: > > The alpha had several fields in its mdproc struct prior to KSE, and KSE > stuck > > them all in mdthread, which isn't quite correct. Specifically, we have > the > > following for mdthread now: > > > > struct mdthread { > > u_long md_flags; > > struct pcb *md_pcbpaddr; /* phys addr of the pcb */ > > struct mdbpt md_sstep[2]; /* two single step breakpoints */ > > u_int64_t md_hae; /* user HAE register value */ > > void *osf_sigtramp; /* user-level signal trampoline */ > > u_int md_kernnest; /* nesting level in the kernel */ > > }; > > > > #define MDP_FPUSED 0x0001 /* Process used the FPU */ > > #define MDP_STEP1 0x0002 /* Single step normal instruction > */ > > #define MDP_STEP2 0x0004 /* Single step branch instruction > */ > > #define MDP_HAEUSED 0x0008 /* Process used the HAE */ > > #define MDP_UAC_NOPRINT 0x0010 /* Don't print unaligned traps */ > > #define MDP_UAC_NOFIX 0x0020 /* Don't fixup unaligned traps */ > > #define MDP_UAC_SIGBUS 0x0040 /* Deliver SIGBUS upon > > unaligned access */ > > #define MDP_UAC_MASK (MDP_UAC_NOPRINT | MDP_UAC_NOFIX | MDP_UAC_SIGBUS) > > > > Out of that structure, it seems obvious that md_pcbpaddr and md_kernnest > need > > to be per-thread. It also seems that the UAC flags need to be > > per-process and need to move back into a md_flags in mdproc. However, I'm > not > > sure about the other ones. What is the HAE and in what contexts is it > used? > > Its used by programs, like the X server, which grovel around in PCI > memory space... Hmm.. In a quick browse through the code, I don't see > where its actually used anymore.. My question is more this: would it be a process property or a thread property? So, if a process turns on HAE access, does a few things, and later on turns it off, it becomes a process property (or even worse, a userland thread property which becomes a pain to handle in KSE). Whereas, if this is something done entirely in a kernel context and the flag is just used to handle things properly while switching and faulting while in kernel context, it can be a thread property. > > Also, what are the single stepping fields used for exactly (details, not > just > > "to implement single stepping :)"). Is the osf_sigtramp just setup once > for > > Single-stepping -- no clue. > > > the entire process, or does it have to be regenerated on the fly all the > time? > > Its used only by OSFF/ECOFF binaries. It is setup each time osf1_sigaction() > is called & used at sigreturn time to point to that process's > sigtramp code. Tru64 does'nt just keep it in a standard place like we > do. So it gets regenerated on the fly and should probably be per-thread? Well, except that do we want multiple threads sending signals down to the userland scheduler? Ugh. I'll leave it per-thread for now. > Drew -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message