This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: backtrace() vs. _Unwind_Backtrace()


On Dec 5, 2003, at 5:26 PM, David Mosberger wrote:

On Fri, 5 Dec 2003 15:39:52 +1300, Bryce McKinlay <bryce@mckinlay.net.nz> said:

Bryce> But on Windows, breaking stack traces would be a regression Bryce> because they do partially work there, although the current Bryce> implementation is pretty bogus when it comes to the Bryce> calling-classloader checks etc.

Is this win32.cc:backtrace()?

Well, there's a bit more to it - somehow we need to get from the frame's IP to the Class and Method ID it belongs to. Using the DWARF info that can be done with _Unwind_GetRegionStart / _Unwind_FindEnclosingFunction and a hashtable. The existing code (StackTrace and NameFinder stuff in gnu/gcj/runtime) does it by looking up symbols and demangling, but thats not robust and not a safe solution for security checks.


DWARF EH was previously enabled for Win32, but problems occurred where exceptions need to be thrown through OS callback frames (that don't have unwind info), which is a common requirement for Win32 code, so it uses SJLJ exceptions for now. So, it would need a way to unwind through info-less OS frames so that the DWARF unwinder can resume unwinding on the other side (ie a generalized MD_FALLBACK_FRAME_STATE_FOR).

Regards

Bryce.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]