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: GCJ Thread Dump


David Daney wrote:

As I said earlier It would probably have to be done from something similar to the GC's stop-the-world. You would print a stack trace for each thread.

The problem I see is that for targets that have no frame pointer. These have to use the DWARF .eh_frame information for generating stacktraces. The stop-the-world uses asynchronous signals and these are not compatible with DWARF exception handling.


On most platforms, we can unwind through signal handlers thanks to MD_FALLBACK_FRAME_STATE_FOR - this is how NullPointerException is implemented.

It might be possible to generate enough eh_frame data to allow getting a stack trace from any instruction, but without adding everything needed for full exception handling (I don't really know not being an expert in this area).

We could compile all GC/libgcj/etc libraries with -fnon-call-exceptions, but what would happen for threads blocked in libc or system calls? I think those might be difficult to backtrace through.


Ah, good point - presumably this is what Andrew was referring to. MD_FALLBACK_FRAME_STATE_FOR would fail if, say, we signaled a thread during a glibc leaf function call which had no unwind info. Non-Linux systems may not have unwind info for their system calls at all.

Bryce


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