Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE301322EAF@probe-2.acclaim-euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Locking DJGPP Code and Data (repost) Date: Fri, 23 Apr 1999 09:59:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Reply-To: djgpp AT delorie DOT com Randy Sorensen writes: > The only method that I've seen for locking code and data when > writing an interrupt handler is to use _go32_dpmi_lock_code() and > _go32_dpmi_lock_data(). Now, I noticed a function called > __dpmi_lock_linear_region() which allows you to lock a whole > block of memory at a given address. These routines are the same thing: the _go32_*() versions are just convenience functions that take normal C pointers rather than a linear address, and translate it into a suitable format before calling the lower level DPMI function. Basically they just add the base address of your data or code selector, to turn a pointer intro a linear address. > Using the method shown above, will it lock all of the code in > the file as well as the global variables? No. Data goes in the data section, while code goes in the text section: these are handled completely separately by the linker. Also, uninitialised variables will go in the bss section, and you may find that the order of output depends in whether a symbol is static or not, so you should make sure that your marker functions have the same static vs. non-static status as the routines they refer to. This whole method of locking things is really bogus, and not terribly reliable. It happens to work with the current compiler and linker implementation, but could break at any time if that changes. For variables, there is a perfectly good solution since you can just lock each one individually, but functions are tricky. I have vaguely thought about trying to scan forward at runtime and locate the end of a function by looking for the cleanup code, but this isn't much of an improvement over using marker functions because it still depends on illicit knowledge of the specific code generation techniques used by your current compiler. Shawn Hargreaves.