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