Xref: news-dnh.mv.net comp.os.msdos.djgpp:2272
Path: news-dnh.mv.net!mv!news.sprintlink.net!in2.uu.net!usenet.eel.ufl.edu!col.hp.com!bubba.ucc.okstate.edu!wizard.uark.edu!engr.engr.uark.edu!alh
From: ALAN L HIGHTOWER <alh AT engr DOT engr DOT uark DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Locking mem under DPMI
Date: Thu, 28 Sep 1995 21:01:04 -0500
Organization: University of Arkansas
Lines: 36
References: <DFLDA9 DOT Hqp AT goodnet DOT com>
Nntp-Posting-Host: engr.engr.uark.edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp


Since a lot of different methods have been thrown around reguarding how 
to lock a function under DPMI, I figure I'll through out another idea.

The most mentioned award goes to the

void start_mem( void ) {}

int foobar(...)
     {
     ....
     }

void end_mem( void ) {}

and use the function pointer to start/end_mem to pinpoint the memory 
start and length of the functions that need locking.

But, as pointed out, this method can fail with static functions and with 
optimizations turned on.

Would it be possible since most functions are long word aligned and 
padded with NOP's to take the associated function pointer and scan along 
long word boundaries till you hit an opcode for either a ret or iret?

How reliable is gcc in always generating an .align 4 directive?  and how 
reliable is it in creating functions with branches to a single ret as the 
last opcode (as opposed to multiple rets)?

Last question, is there any reason preventing auto-locking of the 
iret/callback wrappers and interrupt stack space in subsequent compiles 
of libc.a?  It seems that right after the malloc would be the perfect 
place to go ahead and lock it.  For the .beta3 release I went ahead and 
patched the libc sources, are there any side effect I should be aware of?

Thanks, Alan.