delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/04/25/08:20:48

From: "Randy Sorensen" <randy AT idcomm DOT com>
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 <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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019