Re: Mixing exception handling libraries with non exception handling

[Andrew Haley <aph@redhat.com>]

This top-posting is confusing the hell out of me.  Please stop.

Barry Andrews wrote:
> "Unwinder data for exceptions is generated by the compiler."
> 
> Right, so if the data is there how is it that it gets turned off? Is
> library X saying "Don't load any unwinder data from now on?"

No.

> "In other words, if you
> throw from your code, and catch from your code, and no routine
> in the library is in-between, exceptions should still work."
> 
> Are you saying this is always true? I'm certain there are no other calls
> in between.

Yes, it is always true AFAIAA.  The unwinder reads the data lazily,
so unless it actually finds a stack frame belonging to code that has
no unwinder data, that should have no effect.  The instant the unwinder
sees a frame that it can't unwind, it will abort: there is nothing
else it can do.

Note this: the abort is from within the unwinder, WHILE IT IS
TRYING TO UNWIND A ROUTINE WITH NO UNWINDER DATA.  So, you have
to try to find out why that is happening.

gdb is your friend here.

> Is there no work around for this? It seems so very strange to me.

Compile with -fexceptions.

Andrew.


> Andrew Haley wrote:
>> Barry Andrews wrote:
>>
>>  
>>> So, since it is a runtime thing, I would think I would be able to
>>> control this somehow when my library is loaded. Do you know how
>>> exception handling is turned off anyway? I mean... I can load another C
>>> library ( libc for example ) which obviously does not have exception
>>> handling and it doesn't interfere with my C++ exceptions.
>>>     
>>
>> Unwinder data for exceptions is generated by the compiler.
>>
>> Depending on your platform, libc (or at least some of it) may
>> well be compiled with -fexceptions.  It should only matter if
>> a stack frame belonging to the C library is active on the stack
>> at the time the exception is thrown.  In other words, if you
>> throw from your code, and catch from your code, and no routine
>> in the library is in-between, exceptions should still work.
>>
>> Andrew.
>>
>>  
>>> Andrew Haley wrote:
>>>    
>>>> Barry Andrews wrote:
>>>>
>>>>  
>>>>      
>>>>> I have a 3rd party library ( which I'll call X ) which I believe was
>>>>> compiled with exception handling disabled. Then I have my C++ library
>>>>> which does have exception handling. When I load the X library first
>>>>> into
>>>>> a process, then load my library in the same process, exception
>>>>> handling
>>>>> becomes disabled and the abort() function is called. from unwind-dc2.c
>>>>> if I try to throw an exception in my code. This only happens if I load
>>>>> the X library first. I don't have any control over the X library,
>>>>> i.e. I
>>>>> cannot recompile it.
>>>>>
>>>>> Has anyone run into this before?             
>>>> Yes.
>>>>
>>>>  
>>>>      
>>>>> Is there some compiler option in gcc or
>>>>> #define I should have to keep exception handling enabled when I
>>>>> load my
>>>>> library?
>>>>>             
>>>> No.
>>>>
>>>>  
>>>>      
>>>>> It appears that this is some sort of runtime thing.
>>>>>             
>>>> Yes.  Throwing an exception uses unwinder data which the runtime
>>>> library uses to unwind frames on the stack when an exception is
>>>> thrown.  No unwinder data and you can't throw an exception; it
>>>> can't be helped.
>>>>
>>>> Andrew.
>>>>
>>>>         
>>>     
>>
>>
>>   
> 
>