On Mon, Sep 29, 2008 at 1:50 AM, Duncan Sands <baldrick at free.fr> wrote:> /* snip */Just for another voice in here. 'unwind' and its kin would also be useful for me, especially since this is on platforms without GCC (nor is GCC used in any way in any step anywhere). Why does it generate GCC only constructs anyway, that does not sound very much like the multi-platform that LLVM is targeting.
Hi,> Why does it generate GCC only constructs anyway, that does not sound > very much like the multi-platform that LLVM is targeting.since libgcc is available everywhere llvm is, it's as multi-platform as llvm! If we didn't use libgcc then we'd have to introduce an llvm runtime library. Since it would just duplicate the functionality of libgcc, it would introduce an additional maintenance burden without bringing any real advantage AFAICS. Ciao, Duncan.
I guess Duncan's answer in this thread is the best answer to give: <<Once that [The exception handling stuff needed by llvm-gcc] was done I guess everyone took a breather and kind of forgot about unwind>> So yes, ultimately, unwind will be supported and clang/llvm should provide its own unwinding runtime. Patches welcome :) Cheers, Nicolas OvermindDL1 wrote:> On Mon, Sep 29, 2008 at 1:50 AM, Duncan Sands <baldrick at free.fr> wrote: > >> /* snip */ >> > > Just for another voice in here. 'unwind' and its kin would also be > useful for me, especially since this is on platforms without GCC (nor > is GCC used in any way in any step anywhere). > > Why does it generate GCC only constructs anyway, that does not sound > very much like the multi-platform that LLVM is targeting. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Duncan Sands wrote:> > since libgcc is available everywhere llvm is, it's as multi-platform > as llvm! If we didn't use libgcc then we'd have to introduce an llvm > runtime library. Since it would just duplicate the functionality of > libgcc, it would introduce an additional maintenance burden without > bringing any real advantage AFAICS. >So if there's to be a dependency on libgcc anyway, why not (at least for the time being) have the unwind instruction simply compile into a call to __cxa_throw or whatever libgcc-based mechanism you're thinking of. (Surely there's some boilerplate code to make this work, assuming libgcc is available?) It would be better than compiling to nothing, as it does now. (Though maybe I'm not understanding the complexity of what's involved; it sounds to me like you're just calling a library function). Thanks for all the helpful responses, devs. -- View this message in context: http://www.nabble.com/Unwinds-Gone-Wild-tp18747589p19723406.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
On Sep 29, 2008, at 2:31 AM, Nicolas Geoffray wrote:> I guess Duncan's answer in this thread is the best answer to give: > > <<Once that [The exception handling stuff needed by llvm-gcc] was > done I guess everyone took a breather and kind of forgot about > unwind>> > > So yes, ultimately, unwind will be supported and clang/llvm should > provide its own unwinding runtime.I have tentative plans to bring over a libunwind-based solution to the clang version of "libgcc" when C++ is farther along in clang. -Chris
Whoops, did not send to list: On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote:> libgcc is also available for windows.Really? What license? What restrictions? Any speed impact over the VC runtimes?
On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 <overminddl1 at gmail.com> wrote:> On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes?Don't know about perf, but I think the standard libgcc should just work. AFAIK, mingw-gcc uses it. -Eli