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]

Idea for stack traces


I thought of a way we may be able to implement stack traces for Java 
code without needing any demangler, external binaries, or non-portable 
APIs to convert the stack trace into function names. It should also work 
for stripped binaries with no debugging info or exported dynamic symbol 
tables.

We make the compiler emit some symbol in the text section of each object 
file, after all other Java functions had been emitted. This is treated 
as an opaque pointer to mark the highest address of any method in the class.

During class initialization, some data structure is built up with the 
code pointers (from _Jv_Method) for each method in the class. When a 
stack trace is required, we traverse this data structure to determine 
which method each stack PC value belongs to, and the method name and 
argument values from the _Jv_Method structure are used when printing the 
stack trace.

We'd still need to call an external function to get line numbers (unless 
we write our own dwarf2 interpreter!),  and to deal with native methods, 
but it seems like a nice way to handle the common cases. The data 
structure I mentioned above would be optimized for fast startup/layout 
time and low memory usage, since getting a stack trace is not usually a 
performance-critical thing.

Any reasons why this wouldnt work?

regards

Bryce.



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