Java docs patch: Update libgcj system properties docuementation

[Andrew Haley]

Ranjit Mathew writes:
 > On 4/28/05, Andrew Haley <aph@redhat.com> wrote:
 > > Ranjit Mathew writes:
 > >  >
 > >  > I think it's high time we ditch addr2line and go
 > >  > with something like Casey Marshall's DWARF-2 reader
 > > 
 > > No argument there.  The only thing that stands in the way of doing
 > > this is testing on a wide range of systems.  This means 32-and 64-bit,
 > > big- and little- endian, and systems that use stabs by default.
 > 
 > So the plan could be:
 > 
 > 1. Casey posts his updated patch along with the glue
 > to make the stack-trace infrastructure use it as well
 > as deprecating addr2line.

I think we're past that stage: AFAIK Bryce has a working version
already.

 > Instead of just a DWARF-2 reader, he might want to use the Factory
 > pattern and just provide the DWARF-2 reader as the initial provider
 > with people on other platforms providing stabs, etc.  readers, if
 > needed.

 > 2. Once his basic approach and patch is approved, he can post a
 > heads-up as well as a Request For Testing (RFT) and RFC on the GCJ
 > and GCC lists.
 > 
 > 3. If there are no serious issues or if the issues found are
 > suitably addressed, we can integrate this into GCJ.

Replace that with "once a suitable range of platforms has been tested
...".

 > I know that the "if" in #3 is a big one, but I don't see how else
 > we can make progress on this issue.
 > 
 > For better or for worse, Java libraries and programs throw a lot of
 > exceptions and many a Java programmer almost relies on stack-traces
 > to help debug his program. Sad and ugly, but as far as I have seen,
 > quite prevelant.
 > 
 > Using addr2line not just slows down the program and creates
 > "zombie" processes,

Not IME.  At least, not recently.

 > but on non-binutils-based-platforms (Win32), causes surprising
 > results depending on whether it happens (or not) to be on the PATH.

Andrew.