Date: Thu, 28 Sep 95 22:21 MDT
From: mat AT ardi DOT com (Mat Hostetter)
To: ALAN L HIGHTOWER <alh AT engr DOT engr DOT uark DOT edu>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Locking mem under DPMI
Newsgroups: comp.os.msdos.djgpp
References: <DFLDA9 DOT Hqp AT goodnet DOT com> <Pine DOT SUN DOT 3 DOT 91 DOT 950928204714 DOT 14181A-100000 AT engr DOT engr DOT uark DOT edu>

>>>>> "ALAN" == ALAN L HIGHTOWER <alh AT engr DOT engr DOT uark DOT edu> writes:

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

I maintain that it will work even with optimization turned on,
although it won't work with static functions because gcc reorders
those.  So you'd have to make all locked functions be non-static to be
safe.  Of course, if you throw in an assert to make sure the begin/end
sentinels really are on both sides of the locked code, then everything
should be fine.

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

Scanning for a "ret" opcode wouldn't work.  That opcode might appear
as part of an operand for another instruction within the function.

As for alignment, functions are 16-byte aligned to make the i486
prefetch buffers happy.  .align 4 means align modulo 2**4 bytes in
djgpp's gas (and align modulo 4 bytes in some other gas's, like
Linux!)  However, in an older djgpp I showed that those symbols don't
end up aligned like they should when the final executable is linked!
The same problem happened under Linux...I haven't checked it recently.

-Mat