Date: Mon, 27 Nov 2000 11:38:23 -0800 From: Jake Burkholder <jburkhol@home.com> To: John Baldwin <jhb@FreeBSD.org> Cc: smp@FreeBSD.org Subject: Re: BSD/OS interrupt code Message-ID: <20001127193823.BAA5EBA7A@io.yi.org> In-Reply-To: Message from John Baldwin <jhb@FreeBSD.org> of "Mon, 27 Nov 2000 10:33:05 PST." <XFMail.001127103305.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > On 26-Nov-00 Jake Burkholder wrote: > > Hi, > > > > If anyone with access to the BSD/OS code is interested, I've written > > a little program that runs their interrupt stub code generator in > > userland. You can then abort(); and disassemble the stub from > > the core dump to look at the code all in one piece. Makes it much > > easier to follow. > > > > In case you haven't looked, their interrupt handlers are generated > > by bcopy-ing various blocks of assembler code into an array at > > runtime, and then poking in arguments and relocating branches. > > Hmm. The best way to do this probably is to have stubs with psuedo-relocation > information. I.e., have 1 stub interrupt handler template for each type (fast, > threaded, fast apic, threaded apic, etc.), then have a "relocation" table on > the side that specifies offsets in the code that should receive one of a number > of things: vector number, vector address, etc. Alternatively, we could store > all of that info in a struct (gee, we already do with intrhand :)) and just > have the code always dereference a pointer to that struct and have the > relocation entries simply point to places that that pointer should be written. > Granted, on sparc this could get much uglier (based on my understanding of > relocation address on sparc since an address can be formed across several > instructions. Yuck.) > Yeah, that's basically how its done in the BSD/OS interrupt generator. As I said, I wouldn't want to do this for any architecture that I know of other than x86. Its not overly difficult on x86 because everything is on a byte boundary. sparc, alpha, all the risc architectures that I know anything about have operands at wierd bit offsets in the instruction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001127193823.BAA5EBA7A>