This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: backtrace() vs. _Unwind_Backtrace()
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.