dlls/ntdll/exception.c / unit-at-a-time problem?

[Marcus Meissner]

Hi,

dlls/ntdll/exception.c is showing strange behaviour.

If compiled with -O2 it shows different behaviour than when
compiled with -O2 -fno-unit-at-a-time.

The latter options should only be responsible for reordering functions.

Is reordering of function order a problem with the DEFINE_REGS_ENTRYPOINT()
functions in this file?

I see the original function being moved from after the above asm stub
to below the asm stub for instance, but the relay32.s looks like
it doesnt matter.

Ciao, Marcus

[Marcus Meissner]

On Fri, Oct 28, 2005 at 11:51:50AM +0200, Marcus Meissner wrote:
> Hi,
>
> dlls/ntdll/exception.c is showing strange behaviour.
>
> If compiled with -O2 it shows different behaviour than when
> compiled with -O2 -fno-unit-at-a-time.
>
> The latter options should only be responsible for reordering functions.
>
> Is reordering of function order a problem with the DEFINE_REGS_ENTRYPOINT()
> functions in this file?

The problem is that unit-at-a-time rewrites the argument order(!!!)
of the static EXC_CallHandler() function. (It is allowed to do that,
since it 'sees' all callers within the file.)

Once I remove the static from it, everything works (this makes the
compiler not reorder the arguments).

The comment above it says:

|Call an exception handler, setting up an exception frame to catch exceptions
|happening during the handler execution.
|Please do not change the first 4 parameters order in any way - some exceptions handlers
|rely on Base Pointer (EBP) to have a fixed position related to the exception frame

So must the argument order of EXC_CallHandler() be exactly as is?

Ciao, Marcus

[Alexandre Julliard]

Marcus Meissner  writes:
> So must the argument order of EXC_CallHandler() be exactly as is?

Yes, but that's really a hack, this code should be done in assembly
instead of relying on the compiler behavior.