<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Thanks Serguei!<br>
<br>
Dan<br>
<br>
</tt><br>
On 4/12/12 4:02 PM, <a class="moz-txt-link-abbreviated" href="mailto:serguei.spitsyn@oracle.com">serguei.spitsyn@oracle.com</a> wrote:
<blockquote cite="mid:4F8750DA.6070203@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Looks good.<br>
<br>
Thanks,<br>
Serguei<br>
<br>
On 4/12/12 2:03 PM, Daniel D. Daugherty wrote:
<blockquote cite="mid:4F874320.6010800@oracle.com" type="cite">The
wonderful T&L nightly testing caught an error in my changes
<br>
that were reviewed on this thread. On Linux and Solaris, I
installed <br>
the .debuginfo files for programs in $JAVA_HOME/bin. I made a <br>
mistake in the way I interpreted what I was seeing in the
Windows <br>
code and in $JAVA_HOME/jre/bin. Long story shorter... we
shouldn't <br>
install .debuginfo files for programs. <br>
<br>
7160895 3/3 tools/launcher/VersionCheck.java attempts to launch
.debuginfo <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160895">http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160895</a>
<br>
<br>
The fix is a simple tweak to changes reviewed on this thread: <br>
<br>
diff -r d922195b678d make/common/Program.gmk <br>
--- a/make/common/Program.gmk Wed Apr 11 07:26:35 2012 -0700 <br>
+++ b/make/common/Program.gmk Thu Apr 12 13:38:36 2012 -0700 <br>
@@ -268,6 +268,11 @@ else <br>
$(ZIPEXE) -q $(@F).diz $(@F).debuginfo ; \ <br>
$(RM) $(@F).debuginfo ; \ <br>
) <br>
+ # save ZIP'ed debug info with rest of the program's
build artifacts <br>
+ $(MV) $@.diz $(OBJDIR) <br>
+ else <br>
+ # save debug info with rest of the program's build
artifacts <br>
+ $(MV) $@.debuginfo $(OBJDIR) <br>
endif <br>
endif # PROGRAM_SUPPORTS_FULL_DEBUG_SYMBOLS <br>
endif # ENABLE_FULL_DEBUG_SYMBOLS <br>
<br>
After generation of the program's .debuginfo file, we move it <br>
to the build directory that has the rest of build artifacts, <br>
i.e., .o files etc. We generate the .debuginfo file in the bin <br>
directory because that is where the link phase puts the program
<br>
binary in a Linux and/or Solaris build. <br>
<br>
On Windows, the program, the .map and the .pdb files are
generated <br>
in the build directory and only the program (.exe) is copied to
<br>
the bin directory. So in a Windows build, the program binary is
<br>
in the build directory and the bin directory and on Linux and <br>
Solaris the program binary is only in the bin directory. <br>
<br>
Dan <br>
<br>
<br>
On 4/9/12 2:51 PM, Daniel D. Daugherty wrote: <br>
<blockquote type="cite">Greetings, <br>
<br>
Coming soon to a JDK repo near you! Full Debug Symbols! <br>
<br>
OK, to just a subset of libraries and programs... on Linux and
Solaris... <br>
If you're a Windows fan, the JDK repo has had Full Debug
Symbols support <br>
since way back in JDK1.4.1... Now we're trying get Linux and
Solaris <br>
caught up... <br>
<br>
Runtime Team, we don't have much in the JDK repo, but I tried
to cover <br>
our few libraries and programs. Let me know if I missed
anything... <br>
<br>
Serviceability Team, all of your demos, libraries and programs
are <br>
covered... for some reason, updating those seemed like
reliving old <br>
times and I didn't think you'd mind... :-) <br>
<br>
Here is the webrev URL: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Edcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/">http://cr.openjdk.java.net/~dcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/</a>
<br>
<br>
Thanks, in advance, for any review comments. <br>
<br>
Dan <br>
<br>
P.S. <br>
For those of you that are keeping track of all the FDS <br>
changesets, not everything has hit the various master <br>
repos yet. As a reminder, FDS has to hit the closed <br>
install repo first. The open root and jdk repos along <br>
with the closed deploy repo are in the second wave. And <br>
the hotspot repo, being more Mercurial than his fellow <br>
ghosts, will make his appearance in his own good time <br>
(and via a different set of repos)... <br>
<br>
Apologies to Dickens, of course... :-) <br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>