From: "Randy Sorensen" Newsgroups: comp.os.msdos.djgpp References: <8D53104ECD0CD211AF4000A0C9D60AE301322EAF AT probe-2 DOT acclaim-euro DOT net> Subject: Re: Locking DJGPP Code and Data (repost) Date: Sat, 24 Apr 1999 17:49:04 -0600 Lines: 57 X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 NNTP-Posting-Host: psychosis.idcomm.com X-NNTP-Posting-Host: psychosis.idcomm.com Message-ID: <37224964.0@mindmeld.idcomm.com> X-Trace: 24 Apr 1999 16:44:52 -0700, psychosis.idcomm.com X-NNTP-Posting-Host: superego.idcomm.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 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. >