Stack traces from reflection metadata

[Bryce McKinlay]

Hi Adam,

Sorry I didn't get to look at this patch earlier.

Adam Megacz wrote:

>>printRawStackTrace copies from stackTraceBytes to a suitably aligned
>>array.
>>    
>>
>
>That sounds like a much better idea. I'll reimplement and post a new
>patch.
>
>Any other things I should address?
>  
>

On mainline you'll notice that Throwable now mostly implements the JDK 
1.4 API. The main bit that isn't updated is printStackTrace(), which 
should call getStackTrace() and then print the stack trace based on the 
contents of the returned StackTraceElement array. So, ideally this would 
be implemented as a "back end" for getStackTrace(). Another back end 
would be the existing addr2line lookup support, and yet another would be 
the hypothetical one that uses dwarf2 debug info.

Another thing is that it getAllMethodAddrs() seems to return methods for 
all loaded classes - it would be more efficient to only search in 
initialized classes. Only methods from initialized classes can appear in 
a stack trace. An optimization would be to cache the array of methods 
returned by getAllMethodAddrs() etc and only return a new one if new 
classes have been initialized in the interim.

I guess there is no easy way to identify native frames that arn't 
methods declared in Java.

Is it safe to compare pointers as Java longs? Since longs are signed it 
could potentially fail with 64-bit pointers?

Thanks for working on this, it will be a very useful addition to libgcj.

regards

Bryce.