Date: Tue, 18 Dec 2001 11:02:48 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: alpha@FreeBSD.ORG Subject: Re: mdproc flags in KSE Message-ID: <XFMail.011218110248.jhb@FreeBSD.org> In-Reply-To: <15391.37056.22312.225550@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011218110248.jhb>