On 5/4/14, 1:03 PM, Renato Golin wrote:
On 3 May 2014 17:29, Logan Chien <[email protected]> wrote:
IMO, maybe we can focus on my patch first? Although, it still relies on the
unwinding facilities from libgcc, I feel that we can replace them
step-by-step.
Hi Logan,
This sounds like a good plan. I had a skim through your patch and it
seems good, but I haven't tested any of it.
I modified Clang to include --rtlib=compiler-rt on Linux, but that
still includes both gcc_s and gcc_eh. The idea was to use libc++abi,
or libunwinder as it would be called when moved to compiler-rt bundle.
On Clang, I can only see we replacing each of { gcc_s, gcc_eh }
entirely. It seems to me that doing the unwind move first would be
ideal, especially if we can make it to compiler-rt by that time.
Once the language-independent unwinding library is complete, we
can ifdef (or remove) the function call to libgcc. Does this plan sound
reasonable?
This plan sounds OK to me, but I am a little hesitant. I want to be careful
about how we use the reserved bits of the unwind caches, because some of it is
implementation details of libgcc_s, and I'd rather not have a bunch of "this is
unspecified in the spec, but we're doing it this way because libgcc's unwinder
does it this way" in there permanently. Can you add notes where such
assumptions are made in the libc++abi part so that we can fix them later?
Again, sorry I've been so slow at this.
Jon
Yes. Thanks for working on this!
cheers,
--renato
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
