I suspect it is a problem for you guys as well (unless you do your own memory allocation and force things to be close together). In particular, I wouldn't be surprised if you ran into problems if you put a safe trunc on this line (that's a cursory guess, I haven't actually tested that):
https://github.com/dropbox/pyston/blob/60bab2eabd25f745c15eb967a7fd7d778581b9bc/src/codegen/unwinding.cpp#L92 Do you guys use no-fp-elim in LLVM? libunwind is pretty good about figuring stuff out in those cases, so you may just not have noticed. I will update the patch to address the review comments. On Tue, Oct 6, 2015 at 6:27 PM, Kevin Modzelewski <[email protected]> wrote: > > > On Tue, Oct 6, 2015 at 10:20 AM, Arun Sharma <[email protected]> wrote: > >> On Sun, Oct 4, 2015 at 10:30 PM, Keno Fischer >> <[email protected]> wrote: >> > Bump, does this patch look reasonable? >> >> Yes - looks reasonable to me. Wonder why it wasn't a problem for other >> LLVM JIT users (eg: pyston?). >> > > Now I'm curious too :) Though I don't think our eh_frame and text > sections are that far apart. tbh I don't have a great understanding of the > interaction between MCJIT and libunwind; for instance it also seems odd > that the format that works is REMOTE_TABLE and not (non-remote) TABLE. > > >> >> > unw_dyn_remote_table_t, but >> >> I think you meant to say "Like REMOTE_TABLE, but ..". >> >> Perhaps call it IP_OFFSET instead of TABLE2? >> >> + if (di->format == UNW_INFO_FORMAT_REMOTE_TABLE || >> + di->format == UNW_INFO_FORMAT_REMOTE_TABLE2) >> >> Could you wrap this in is_remote_table()? >> >> > + ip_base = segbase; >> >> Rename it something neutral that works for both the segbase and ip_base >> cases? >> >> -Arun >> >> _______________________________________________ >> Libunwind-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/libunwind-devel >> > >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
