Re: [AD] END_OF_FUNCTION problems in gcc 3.4?

[Serge Semashko <serge@xxxxxxxxxx>]

Sven Sandberg wrote:

> It seems gcc 3.4 includes changes that may break the functionality of 
> END_OF_FUNCTION(). 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 END_OF_FUNCTION(func) construct in djgpp relies on a particular 
> ordering of functions: it declares a new function (called func_end), and 
> then LOCK_FUNCTION(func) locks all code between func and func_end. This 
> clearly does not work if func and func_end have been reordered.
>
> I guess this could be fixed in Allegro's source files, by using -O1 
> instead of -O2 on all files using LOCK_FUNCTION() (the gcc changelog 
> says "As a temporary workaround, -fno-unit-at-a-time can be used, but 
> this scheme may not be supported by future releases of GCC.").
>
> But a bigger problem is that users of Allegro need to address the same 
> issue. We could simply add to the documentation of END_OF_FUNCTION() 
> that djgpp users should not use -O2 or higher under gcc 3.4 or higher. 
> But it's not nice that they have to know about it, especially since 
> people may develop under other systems and not see the bug, and in any 
> case it may be a hard to find bug.
>
> Does anyone know more about this optimization? I mean, maybe in this 
> particular case func and func_end will not be rearranged, or maybe there 
> is some better way to guarantee that they will not be rearranged. (E.g., 
> the same 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 to reorder func and func_end since none 
> of them calls the other, but can we be sure?)

I think that DJGPP people should be asked to remove support for this 
optimization from their build of compiler. This can solve all the 
problems, this optimization can affect not only Allegro users, so it is 
dangerous anyway.

If they use this optimization, the following example from DJGPP docs 
will be invalid so they need to fix either docs or the compiler:

Example
-------

void my_handler()
{
}

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


Also maybe using the following code can help to solve these locking issues:

#include <crt0.h>
int _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY;