backtrace() vs. _Unwind_Backtrace()

Andrew Haley
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.


More information about the Java mailing list