Re: GCJ Stack Traces for arm-wince-pe on gcj 3.4.3

[Craig Vanderborgh <craigvanderborgh at gmail dot com>]

Andrew:  thanks for the reply.  I would also like to thank Marco for
his reply, and would like to suggest that he extend JNC so that it
supports Windows CE.  Then I could work on something else!  For what
it's worth, we'd be happy to pay some serious money for something like
JNC for WinCE.

I am still pretty fuzzy on what code generation options should be used
to generate stack frames that could be unwound.  The things I have
tried so far (such as -mapcs-32) have not resulted in stack frames
that I could unwind.  Any suggestions on what the right compiler
options might be?

Our applications are almost entirely AOT-compiled to native
arm-wince-pe objects.  So I could potentially look up and display
functions from the linked part of the application in my stack trace,
right?  That would be much better than nothing and would be a workable
solution for the near term.

On Wed, Jan 28, 2009 at 5:13 AM, Andrew Haley <aph@redhat.com> wrote:
> Craig Vanderborgh wrote:
>
>> We have been busy bringing up gcj 3.4.3 on arm-wince-pe (Windows CE 5
>> and 6).  At this point everything is pretty much working (garbage
>> collection, hash synchronization, reflection, class loading, etc.) on
>> real-world GCJ applications.
>>
>> What we are still lacking (and have always lacked..) is stack traces.
>> I understand that some work has been done in the most recent versions
>> to implement an arm-elf unwinder that supposedly works and that stack
>> traces are available now, at least for arm-elf-linux.  We considered
>> porting this (gcc-4.1.1) and using this version of gcj, but the
>> classpath-based libgcj is too big for us to handle on WinCE embedded
>> systems.  That's one reason why we're going for gcc-3.4.3.
>
> Fair enough, if it does what you need.
>
>> What could we do to implement stack traces on gcc-3.4.3?  What would
>> be the best approach?  One idea we're considering is to alter the code
>> generation in gcc/gcj so that the ARM function calls adhere to a
>> simpler (unwindable) format.  It seems like this would be the least
>> invasive approach, since we then could continue to use SJLJ exceptions
>> in gcj.  Is this the best approach, or would it be possible/prudent to
>> backport the ARM unwinder from gcc-4.1.1+?
>
> According to svn log, I added the ARM EABI backtrace on 2007-08-08.
> It is not present in any gcc release before 4.3.0.
>

I have a version of 4.1.1 with that stuff in it - it came that way.
So I don't really understand this.  I tried to use that (4.1.1)  with
SJLJ exceptions disabled and your ARM EABI backtrace stuff configured.
 The gcc/gcj compilers configured this way ICE'd on any but the
simplest "Hello World" compilation units.  This is another reason we
"fled" back to something a little more familiar.  I'm interested in
trying to get something really recent like 4.3.0 working on
arm-wince-pe, but am somewhat dissuaded by the apparent magnitude of
the task.

> As I understand it, gcc-3.4.3 should be perfectly capable of generating
> APCS-compatible code that has a stack chain you can unwind.  The only
> problem you'll have is converting a code address to the handle of a
> class.
>
> Andrew.
>
>
>

Thanks again, Andrew and Marco...

Craig Vanderborgh
Voxware Incorporated