backtrace() vs. _Unwind_Backtrace()

Tue Dec 9 09:55:00 GMT 2003

Bryce McKinlay writes:
 > On Dec 9, 2003, at 12:33 AM, Andrew Haley wrote:
 > 
 > > Bryce McKinlay writes:
 > >> On Dec 7, 2003, at 12:21 AM, Andrew Haley wrote:
 > >>
 > >>> I don't want it to sound like I'm opposed to the approach of calling
 > >>> _Unwind_Backtrace() directly. It sounds quite a clean idea. 
 > >>> However,
 > >>> not every architecture supports DWARF2, and if we have a new
 > >>> architecture for unwinding we need to support those targets too.
 > >>
 > >> The thing is, backtrace() alone doesn't help us much. Without DWARF2,
 > >> we can't find the start of the function, and can't lookup the
 > >> Class/Method. So why bother?
 > >
 > > All we need is a method that maps pc->name. We know that we can use
 > > addr2line to do that, and we are about to get a demangler that we can
 > > link into libgcj.
 > 
 > It needs to map pc->Class/_Jv_Method, not just a name. Mapping to a
 > name (eg symbol lookup/demangling) is insufficient because
 > different classes, with different privileges, can have the same
 > name. Someone could, for example, name their class
 > java.lang.Whatever and potentially bypass security checks.
Good point. I think there are ways round this. Ideally, we'd want
something like addr2line, but instead of returning a name it'd return
an entry point. I can think of a way to do that.
 > Admittedly this problem only really applies to security checks and
 > not diagnostic stack traces, but I think its better to pursue a
 > solution that works for everything.
Your approach for DWARF 2 targets looks sound to me.
There's an issue with CNI, though: at present the class only sees the
address of the PLT entry of a native method, not the address of the
method itself. I think we can get around this if we use -Bsymbolic
when linking a shared library.
Andrew.