Re: 2nd posting: exceptions and asm() blocks on x86

["John S. Yates, Jr." <jyates at netezza dot com>]

"Falk Hueffner" <falk.hueffner@student.uni-tuebingen.de> writes:

> "John S. Yates, Jr." <jyates@netezza.com> writes:
>
> > I have recently debugged an exception failure in our multi-precision
> > arithmetic package.  The problem was that when overflow was signaled
> > the catch block was never found.
> > 
> > [...]
> >
> > Is this a bug or an expected limitation?  If the latter, is it
> > documented anywhere?
>
> It's an expected limitation. asm's are not supposed to change the
> control flow. The manual could probably more explicit about this... In
> this case, most likely the stack unwinder is missing the additional
> information normally generated by gcc.

Then gcc must explicitly be going out of its way to interrupt
exception handling across the asm() block.  An exception raised
immediately before or following the block is handled properly.

I assume you are not suggesting that calls out from asm() blocks
are forbidden.  The gcc manual give an explicit example of this:

   Here is an example of multiple instructions in a
   template; it assumes the subroutine _foo accepts
   arguments in registers 9 and 10: 


   asm ("movl %0,r9\n\tmovl %1,r10\n\tcall _foo"
        : /* no outputs */
        : "g" (from), "g" (to)
        : "r9", "r10");

If your explanation is correct, that is that a call to an
exception-raising, noreturn function is viewed as changing
control flow, then what is gcc's stance on using instructions
that raise exceptions within asm() blocks?  The manual gives
explicit examples of use asm() blocks to emit floating point
instructions (68881's fsinx, x86 fsincos and fyl2xp1, etc).
Does this means that an exception raised by an fadd emitted
by the compiler will be handled properly but an exception
raised by an fadd within an asm() block cannot be caught?
And if that is the actual behaviour with today's code how
can it be deemed not a bug?

As a gentle prod I will mention that I have implemented the
same multi-precision classes that I mentioned in my original
posting under WindRiver's Diab PPC compiler.  There the call
to signal_overflow() within their asm() is handled properly.

/john
-- 
John S. Yates, Jr.   508 665-6897 (voice)
Netezza Inc          508 665-6811 (fax)
200 Crossing Blvd.   Framingham, MA 01701