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

[Falk Hueffner]

"John S. Yates, Jr." <jyates@netezza.com> writes:

> "Falk Hueffner" <falk.hueffner@student.uni-tuebingen.de> writes:
> > 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.

No. It just does not add required information for the stack unwinder.

> 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?

Is it possible that you're confusing C++ exception and hardware traps?
Those two concepts are in no way related with g++. Some C++ compilers
catch hardware traps and make C++ exceptions of them, but g++ doesn't.
Therefore, you cannot throw C++ exceptions from asm at all.

> 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?

The behaviour should be identical: the trap is handled not at all by
the compiler.

To get back to your actual problem: I don't think there's a portable
way to create a call in a gcc asm through which exceptions can be
thrown.  Maybe you could try to generate the required .eh_frames
manually, I think the Linux kernel does this somewhere.

-- 
	Falk