Mail Archives: djgpp/1999/04/25/08:20:48
Is there some good reason why the developers of GCC for DOS (DJ, and others)
don't implement a better system? I realize it was ported from UNIX, which
is PM all the time... but still so, if the software was changed to
re-organize the order of functions and thus rendering this method to be
useless, wouldn't he kind of be forced to implement a better method? How
else are you supposed to find the size of a function?
So, the code I posted wouldn't lock the variables... but the code would be
locked, right?
-Randy
randy AT idcomm DOT com
Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk> wrote in message
news:8D53104ECD0CD211AF4000A0C9D60AE301322EAF AT probe-2 DOT acclaim-euro DOT net...
> 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 -