On 4/12/12 8:39 AM, Dmitry Samersoff wrote:
Dan,
We link two semantically different options together and it make me
uncomfortable with this fix.
This JDK fix has the exact same semantics as the HotSpot
changes that I did for FDS. As I keep saying over and over
and over, a Full Debug Symbols build is pretty much the same
thing as Fastdebug build. If you want FDS, you have to give
up some optimizations.
Why do we need to change compiler flags besides symbol generation ?
e.g. for gcc -O3 -g3 is perfectly valid combination.
You'd have to dig into the history of why a FASTDEBUG flavor build
chose the options that it did. All I'm doing is using their research.
Dan
-Dmitry
On 2012-04-12 17:50, Daniel D. Daugherty wrote:
On 4/11/12 7:24 PM, Mikael Vidstedt wrote:
On 2012-04-10 14:53, Daniel D. Daugherty wrote:
On 4/10/12 3:47 PM, Dmitry Samersoff wrote:
1.
239 # If Full Debug Symbols is enabled, then we want the same
debug and
240 # optimization flags as used by FASTDEBUG. We also want all the
241 # debug info in one place (-xs).
Sorry! I'm later at the party. What is the reason of enforcing
certain optimization level with FDS?
FDS doesn't enforce a certain optimization level. FDS takes advantage
of work that other people have done to find optimization levels that
work with fastdebug builds. This isn't so much an issue with the JDK
(that I know of), but it is an issue with HotSpot. With HotSpot,
fastdebug builds often use a lower optimization level than fully
optimized builds because the compiler can't handle it. When FDS is
enabled, we're basically doing a fastdebug build so we piggy back
off of the same settings.
Sorry for being a bit slow here, but I'm still not sure I understand
the comment. Can you clarify how the build process works and where the
FASTDEBUG optimization flags are used?
In a FULL_DEBUG_SYMBOLS=0 build, the system works as it did before
which means that OPT and FASTDEBUG flavor builds have their own set
of compiler flags. So when you are doing an OPT build (the default),
there is a default set of compiler flags. Of course, compiler flags
can be overridden on a per-file basis for cases when the compiler
with the default options is found to be buggy with a particular file.
Similarly a FASTDEBUG build has a different set of default compiler
flags and the default can also be overridden on a per-file basis.
In a FULL_DEBUG_SYMBOLS=1 build, we override the OPT default set of
compiler flags with the FASTDEBUG default set of compiler flags.
This is because an FULL_DEBUG_SYMBOLS=1 build is pretty much the
same as a FASTDEBUG build.
Just to complete the picture, there is a master build flag for
building the entire JDK with a DEBUG flavor. That build option is
pretty much a sledgehammer that turns off any optimizations and
enables full debug options. I have no idea if anyone even uses
that build option anymore.
Of course, HotSpot is different. HotSpot has FASTDEBUG, but instead
of OPT it has PRODUCT. And HotSpot has a number of other build flavors,
e.g., DEBUG, OPTIMIZED, PROFILED, ...
Dan
Thanks,
Mikael
2.
192 ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1)
193 ifeq ($(ZIP_DEBUGINFO_FILES),1)
194 (set -e ; \
195 $(CD) $(OBJDIR) ; \
196 $(ZIPEXE) -q $(PROGRAM).diz $(PROGRAM).map $(PROGRAM).pdb ; \
197 $(RM) $(PROGRAM).map $(PROGRAM).pdb ; \
198 )
199 endif
200 endif
No fallback on zip error here. No ideas what we should do if zip
fails, so it just a FYI.
The 'set -e' on line 194 means that the build will fail. That is
intentional. If the command fails unexpectedly, then the build
should fail and hopefully with a useful error message.
Dan
-Dmitry
On 2012-04-11 01:17, Daniel D. Daugherty wrote:
Thanks Serguei!
Dan
On 4/10/12 2:51 PM, [email protected] wrote:
Dan,
It is good.
Thanks,
Serguei
On 4/9/12 1:51 PM, Daniel D. Daugherty wrote:
Greetings,
Coming soon to a JDK repo near you! Full Debug Symbols!
OK, to just a subset of libraries and programs... on Linux and
Solaris...
If you're a Windows fan, the JDK repo has had Full Debug Symbols
support
since way back in JDK1.4.1... Now we're trying get Linux and
Solaris
caught up...
Runtime Team, we don't have much in the JDK repo, but I tried to
cover
our few libraries and programs. Let me know if I missed
anything...
Serviceability Team, all of your demos, libraries and programs are
covered... for some reason, updating those seemed like reliving
old
times and I didn't think you'd mind... :-)
Here is the webrev URL:
http://cr.openjdk.java.net/~dcubed/fds_revamp/7071907-webrev/0-jdk8-jdk/
Thanks, in advance, for any review comments.
Dan
P.S.
For those of you that are keeping track of all the FDS
changesets, not everything has hit the various master
repos yet. As a reminder, FDS has to hit the closed
install repo first. The open root and jdk repos along
with the closed deploy repo are in the second wave. And
the hotspot repo, being more Mercurial than his fellow
ghosts, will make his appearance in his own good time
(and via a different set of repos)...
Apologies to Dickens, of course... :-)
