Re: [AD] END_OF_FUNCTION problems in gcc 3.4?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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;





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/