Mail Archives: djgpp/1999/04/23/04:59:57
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.
- Raw text -