* Mixing exception handling libraries with non exception handling @ 2008-08-04 14:40 Barry Andrews 2008-08-04 15:00 ` Andrew Haley 0 siblings, 1 reply; 8+ messages in thread From: Barry Andrews @ 2008-08-04 14:40 UTC (permalink / raw) To: gcc-help Hi All, 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? Is there some compiler option in gcc or #define I should have to keep exception handling enabled when I load my library? It appears that this is some sort of runtime thing. Many many thanks for any guidance! -B ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mixing exception handling libraries with non exception handling 2008-08-04 14:40 Mixing exception handling libraries with non exception handling Barry Andrews @ 2008-08-04 15:00 ` Andrew Haley [not found] ` <48971DE4.90804@gmail.com> 0 siblings, 1 reply; 8+ messages in thread From: Andrew Haley @ 2008-08-04 15:00 UTC (permalink / raw) To: Barry Andrews; +Cc: gcc-help 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <48971DE4.90804@gmail.com>]
* Re: Mixing exception handling libraries with non exception handling [not found] ` <48971DE4.90804@gmail.com> @ 2008-08-04 15:26 ` Andrew Haley [not found] ` <48972282.2060208@gmail.com> 0 siblings, 1 reply; 8+ messages in thread From: Andrew Haley @ 2008-08-04 15:26 UTC (permalink / raw) To: Barry Andrews; +Cc: gcc-help 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. >> >> > > ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <48972282.2060208@gmail.com>]
* Re: Mixing exception handling libraries with non exception handling [not found] ` <48972282.2060208@gmail.com> @ 2008-08-04 15:54 ` Andrew Haley [not found] ` <489728DE.50403@gmail.com> 2008-08-05 14:33 ` Ian Lance Taylor 0 siblings, 2 replies; 8+ messages in thread From: Andrew Haley @ 2008-08-04 15:54 UTC (permalink / raw) To: Barry Andrews; +Cc: gcc-help 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. >>>> >>>> >>> >> >> >> > > ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <489728DE.50403@gmail.com>]
* Re: Mixing exception handling libraries with non exception handling [not found] ` <489728DE.50403@gmail.com> @ 2008-08-04 16:25 ` Andrew Haley 0 siblings, 0 replies; 8+ messages in thread From: Andrew Haley @ 2008-08-04 16:25 UTC (permalink / raw) To: Barry Andrews; +Cc: gcc-help Barry Andrews wrote: > Andrew Haley wrote: >> >> 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. >> > And that's why it aborts for me. There is no unwinder data at all. I'll > keep digging, but there are lots of internals here to debug. OK, so you have to look at a gdb backtrace to see which routine with no unwinder data is being unwound. >>> Is there no work around for this? It seems so very strange to me. >>> >> >> Compile with -fexceptions. >> > Yeah, I have that. Doesn't help. Did it work for you? Yes, always. Andrew. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mixing exception handling libraries with non exception handling 2008-08-04 15:54 ` Andrew Haley [not found] ` <489728DE.50403@gmail.com> @ 2008-08-05 14:33 ` Ian Lance Taylor [not found] ` <489867BB.1090204@gmail.com> 1 sibling, 1 reply; 8+ messages in thread From: Ian Lance Taylor @ 2008-08-05 14:33 UTC (permalink / raw) To: Andrew Haley; +Cc: Barry Andrews, gcc-help Andrew Haley <aph@redhat.com> writes: >> Is there no work around for this? It seems so very strange to me. > > Compile with -fexceptions. Or -funwind-tables. Ian ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <489867BB.1090204@gmail.com>]
* Re: Mixing exception handling libraries with non exception handling [not found] ` <489867BB.1090204@gmail.com> @ 2008-08-05 15:28 ` Andrew Haley 2008-08-05 16:23 ` Ian Lance Taylor 1 sibling, 0 replies; 8+ messages in thread From: Andrew Haley @ 2008-08-05 15:28 UTC (permalink / raw) To: Barry Andrews; +Cc: Ian Lance Taylor, gcc-help Barry Andrews wrote: > Ian Lance Taylor wrote: >> Andrew Haley <aph@redhat.com> writes: >> >> >>>> Is there no work around for this? It seems so very strange to me. >>>> >>> Compile with -fexceptions. >>> >> >> Or -funwind-tables. >> > Unfortunately neither flag helps. I think the only way is to rebuild > library X. Well, yes. That's what we said: Compile with -fexceptions. This means Library X. Andrew. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Mixing exception handling libraries with non exception handling [not found] ` <489867BB.1090204@gmail.com> 2008-08-05 15:28 ` Andrew Haley @ 2008-08-05 16:23 ` Ian Lance Taylor 1 sibling, 0 replies; 8+ messages in thread From: Ian Lance Taylor @ 2008-08-05 16:23 UTC (permalink / raw) To: Barry Andrews; +Cc: Andrew Haley, gcc-help Barry Andrews <titanandrews@gmail.com> writes: > Ian Lance Taylor wrote: >> Andrew Haley <aph@redhat.com> writes: >> >> >>>> Is there no work around for this? It seems so very strange to me. >>>> >>> Compile with -fexceptions. >>> >> >> Or -funwind-tables. >> > Unfortunately neither flag helps. I think the only way is to rebuild > library X. Yes, one of those options is required while building library X. Ian ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-08-05 16:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-08-04 14:40 Mixing exception handling libraries with non exception handling Barry Andrews
2008-08-04 15:00 ` Andrew Haley
[not found] ` <48971DE4.90804@gmail.com>
2008-08-04 15:26 ` Andrew Haley
[not found] ` <48972282.2060208@gmail.com>
2008-08-04 15:54 ` Andrew Haley
[not found] ` <489728DE.50403@gmail.com>
2008-08-04 16:25 ` Andrew Haley
2008-08-05 14:33 ` Ian Lance Taylor
[not found] ` <489867BB.1090204@gmail.com>
2008-08-05 15:28 ` Andrew Haley
2008-08-05 16:23 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).