X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Fri, 23 Jul 2004 17:14:43 +0200
From: Sven Sandberg <svens AT it DOT uu DOT se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Problem with _go32_dpmi_lock_code in gcc 3.4
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: regulus2.student.uu.se
Message-ID: <41012b40$1@griseus.its.uu.se>
X-Trace: griseus.its.uu.se 1090595648 regulus2.student.uu.se (23 Jul 2004 17:14:08 +0100)
Lines: 66
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello,

It seems gcc 3.4 includes changes that may break the suggested use of
_go32_dpmi_lock_code(). This affects Allegro users (I posted a similar
message on Allegro's mailing list). From
http://gcc.gnu.org/gcc-3.4/changes.html :

    The new unit-at-a-time compilation scheme has several compatibility
    issues:
      * The order in which functions, variables, and top-level asm
        statements are emitted may have changed. Code relying on some
        particular ordering needs to be updated. The majority of such
        top-level asm statements can be replaced by section attributes.

This "unit-at-a-time compilation scheme" is a new optimization in gcc
3.4, implied by -funit-at-a-time or -O2.

The documentation for _go32_dpmi_lock_code()
(http://www.delorie.com/djgpp/doc/libc/libc_441.html) suggests the
following usage:

    void my_handler()
    {
    }

    void lock_my_handler()
    {
      _go32_dpmi_lock_code(my_handler, (unsigned long)(lock_my_handler -
                           my_handler));
    }

Clearly, this will break if my_handler and lock_my_handler are
rearranged. Any suggestions for how to use _go32_dpmi_lock_code() when
functions may be rearranged, other than using -O1?


It would be particularly nice if there was a solution that could be
incorporated in Allegro headers, so that Allegro users did not have to
change their code or compiler options. Currently, Allegro defines the macros

    #define END_OF_FUNCTION(func) void func##_end(void) {}
    #define LOCK_FUNCTION(func) \
       _go32_dpmi_lock_code(func, (unsigned long)(func##_end-func));

Thus, the Allegro equivalent to the example above would be

    void my_handler()
    {
    }
    END_OF_FUNCTION(my_handler)

    void lock_my_handler() {
       LOCK_FUNCTION(my_handler)
    }

So it would be great if there is a solution that can be incorporated in 
those macros, although I understand it may not be possible. Also, in the
particular example of Allegro's LOCK_FUNCTION(), it's conceivable that
my_handler and my_handler_end are never rearranged: the gcc changelog
says that functions are topologically sorted with respect to the call
graph. If this is the only rule by which functions are rearranged, there
is no need for gcc to reorder func and func_end since none of them calls
the other, but can we be sure? Is there any expert out there who can
confirm/deny this? Thanks for any help,

Sven Sandberg