public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* GCJ Stack Traces for arm-wince-pe on gcj 3.4.3
@ 2009-01-28  3:22 Craig Vanderborgh
  2009-01-28 10:16 ` Andrew Haley
  0 siblings, 1 reply; 4+ messages in thread
From: Craig Vanderborgh @ 2009-01-28  3:22 UTC (permalink / raw)
  To: java

Hello Everyone:

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.

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+?

Any comments appreciated.

Thanks in advance,
Craig Vanderborgh
Voxware Incorporated

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: GCJ Stack Traces for arm-wince-pe on gcj 3.4.3
  2009-01-28  3:22 GCJ Stack Traces for arm-wince-pe on gcj 3.4.3 Craig Vanderborgh
@ 2009-01-28 10:16 ` Andrew Haley
  2009-01-28 16:34   ` Craig Vanderborgh
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Haley @ 2009-01-28 10:16 UTC (permalink / raw)
  To: Craig Vanderborgh; +Cc: java

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.

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: GCJ Stack Traces for arm-wince-pe on gcj 3.4.3
  2009-01-28 10:16 ` Andrew Haley
@ 2009-01-28 16:34   ` Craig Vanderborgh
  2009-01-28 16:38     ` Andrew Haley
  0 siblings, 1 reply; 4+ messages in thread
From: Craig Vanderborgh @ 2009-01-28 16:34 UTC (permalink / raw)
  To: java, Andrew Haley

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: GCJ Stack Traces for arm-wince-pe on gcj 3.4.3
  2009-01-28 16:34   ` Craig Vanderborgh
@ 2009-01-28 16:38     ` Andrew Haley
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Haley @ 2009-01-28 16:38 UTC (permalink / raw)
  To: Craig Vanderborgh; +Cc: java

Craig Vanderborgh wrote:
> 
> 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?

I would have expected that to work.  Strict APCS compliance requires
an unwindable stack chain.  What's wrong?

> 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.

Sure.

Andrew.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2009-01-28 16:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-28  3:22 GCJ Stack Traces for arm-wince-pe on gcj 3.4.3 Craig Vanderborgh
2009-01-28 10:16 ` Andrew Haley
2009-01-28 16:34   ` Craig Vanderborgh
2009-01-28 16:38     ` Andrew Haley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).