Now that we have a new libgcj in FC-5, azureus logging seems to be working. I've been comparing log files between Sun JRE and gcj runs, and have filed 1 GNU Classpath bug so far.
One thing that is annoying is that I'm not getting line numbers in the azureus debug output. Azureus' calls to StackTraceElement.getLineNumber() always result in -1. I have the azureus debug RPM installed, and just assumed that this would be enough to get line number info. Maybe I'm misremembering all this. Should StackTraceElement.getLineNumber() return good info for bc-compiled code?
AG
Anthony Green writes:
Now that we have a new libgcj in FC-5, azureus logging seems to be working. I've been comparing log files between Sun JRE and gcj runs, and have filed 1 GNU Classpath bug so far.
One thing that is annoying is that I'm not getting line numbers in the azureus debug output. Azureus' calls to StackTraceElement.getLineNumber() always result in -1. I have the azureus debug RPM installed, and just assumed that this would be enough to get line number info. Maybe I'm misremembering all this. Should StackTraceElement.getLineNumber() return good info for bc-compiled code?
Yes, it should. However, StackTraceElement.getLineNumber() doesn't work with separate debuginfo.
Andrew.
Andrew Haley wrote:
Anthony Green writes:
Now that we have a new libgcj in FC-5, azureus logging seems to be working. I've been comparing log files between Sun JRE and gcj runs, and have filed 1 GNU Classpath bug so far.
One thing that is annoying is that I'm not getting line numbers in the azureus debug output. Azureus' calls to StackTraceElement.getLineNumber() always result in -1. I have the azureus debug RPM installed, and just assumed that this would be enough to get line number info. Maybe I'm misremembering all this. Should StackTraceElement.getLineNumber() return good info for bc-compiled code?
Yes, it should. However, StackTraceElement.getLineNumber() doesn't work with separate debuginfo.
We could also solve this by having the Java RPMs strip the rest of the debug info, but NOT the .debug_line section. .debug_line is quite compact compared to the rest of the debug info: it adds less than 1MB to libgcj.so. Is this extra size worth it to always have stack trace line numbers?
We would want to make sure that we have a fast line number lookup before doing that, though. Currently, line number lookups have a big negative performance impact on certain applications that log stack traces frequently.
Bryce
Bryce McKinlay writes:
Andrew Haley wrote:
Anthony Green writes:
Now that we have a new libgcj in FC-5, azureus logging seems to be working. I've been comparing log files between Sun JRE and gcj runs, and have filed 1 GNU Classpath bug so far.
One thing that is annoying is that I'm not getting line numbers in the azureus debug output. Azureus' calls to StackTraceElement.getLineNumber() always result in -1. I have the azureus debug RPM installed, and just assumed that this would be enough to get line number info. Maybe I'm misremembering all this. Should StackTraceElement.getLineNumber() return good info for bc-compiled code?
Yes, it should. However, StackTraceElement.getLineNumber() doesn't work with separate debuginfo.
We could also solve this by having the Java RPMs strip the rest of the debug info, but NOT the .debug_line section. .debug_line is quite compact compared to the rest of the debug info: it adds less than 1MB to libgcj.so. Is this extra size worth it to always have stack trace line numbers?
We would want to make sure that we have a fast line number lookup before doing that, though. Currently, line number lookups have a big negative performance impact on certain applications that log stack traces frequently.
Right indeed. If we have a line number lookup of our own, and if it's fast enough, it can just look in the debuginfo files.
Andrew.
Andrew Haley wrote:
Right indeed. If we have a line number lookup of our own, and if it's fast enough, it can just look in the debuginfo files.
Yeah, there's that option too. But do we want to provide line numbers even if debuginfo is not installed? Given that the space cost is small, I think it would be nice. The debuginfo packages arn't widely distributed and can easily get out of sync with the real binaries.
Bryce
Bryce McKinlay writes:
Andrew Haley wrote:
Right indeed. If we have a line number lookup of our own, and if it's fast enough, it can just look in the debuginfo files.
Yeah, there's that option too. But do we want to provide line numbers even if debuginfo is not installed?
That's an interesting question. I would argue not, because line numbers are unquestionably debuginfo. I suppose it all depends on whether you consider line numbers to be of use to people who aren't actively debugging: I don't. But I can recognize the argument that the line number table is small, so why not include it?
Andrew.
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Anthony Green -
Bryce McKinlay