Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Matt Benson wrote:
--- Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
[SNIP]
I guess the primary job of these scripts is to
setup the classpath
correctly.
We can get of them under assumption that everyone
has a cpptasks
(which is needed for native code compilation) and
antcontrib packages
installed with the Ant.
And as soon as we get rid of the need for
cpptasks ;)
I wonder if we can add them to the classpath in the
first ant-script we
run, and then have them avail for invoked scripts.
Seriously, if the native build is switched to a make
approach, it wouldn't be impossible to remove the ac
dependency from what I can see in the drlvm buildfile.
Personally I would probably prefer the cpptasks be
used but grudgingly admit that actual C hackers are
probably more accustomed to make. ;)
Beyond that, however, antcontrib is THE most often
mentioned/recommended 3rd-party package on Ant's user
lists;
Why don't you guys fold this into ant then?
more than one of its developers are also Ant
committers. I don't know that I see the harm in
simply requiring that the user install antcontrib (and
cpptasks, while it is used). The user can simply drop
the jars into $ANT_HOME/lib (actually I don't set
ANT_HOME but let the location of the invoker script
along my PATH pick it up, but that's a different
story).
Because it's annoying when you need to modify standard tools just for
one project...
On shared installations (with Ant = 1.6),
the user can install in ${user.home}/.ant/lib or
supply the -lib option at the commandline. If the
-lib option is chosen, that can be configured with
ANT_ARGS .
Oh, that's cool. Still, why don't you let me augment ant's lib at
runtime from w/in the ant script? I would assume it would be related to
initial parsing and recognition of elements in the script, but some kind
of late-binding would be nifty...
My cygwin Harmony classpath build
environment actually uses the -lib option to include
the ecj jar, for example.
So there's no way to do a fork-like thing - let a top ant script setup
the environment and then launch the script that does the work?
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Rana Dasgupta wrote: Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? The solution I think is to get rid of the build.sh/build.bat wrappers and fix the ant scripts... I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Weldon Washburn wrote:
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
When you do that, no one else can participate... try to do things like
this here...
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++ build.bat (working copy)
@@ -138,7 +138,7 @@
)
REM Note: vm.jitrino is always complied in release mode, otherwise it
makes VM
debug too slow
-CALL %ANT_COMMAND% -f make/build.xml -Dvm.jitrino.cfg=release %*
+CALL %ANT_COMMAND% -f make/build.xml %*
I think it's time to get rid of the build.bat/build.sh once and for all...
Or simply just pass the args you need to the script.
GOTO THEEND
Mods to drlvm/trunk/build/make/components/vm/jitrino.xml
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
For some unknown reason, svn diff wants to report that every line has
changed in common_vm.xml. Probably something to do with carriage
return line feed. In any case the mods to
drlvm/trunk/build/make/targets/common_vm.xml. These are the same mods
that were reported in the email titled, [DRLVM] questions about
build.bat -DEBUILD_CFG=debug -DCXX=msvc. They are repeated here for
completeness:
- select os=win cxx=msvc
compilerarg value=/Od /
compilerarg value=/MTd /
compilerarg value=/D_DEBUG /
/select
A new svn update of both classlib and drlvm was downloaded this
morning. The above mods were applied. And, finally, a build.bat
-DEBUILD_CFG=debug -DCXX=msvc was run. The binary is now debuggable
with MS Visual Studio.
Question: Should the above be bundled up as a JIRA patch?
I think the goal should be allowing people interested in this mode to
simply pass a sensible flag/property, such that for everyone else, there
is no change.
And no - you're a committer, so you can apply it. But please, make this
one-off condition something that you trigger w/ a flag passed to
build.bat/.sh (until we get rid of it), rather than something everyone
has to deal with.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 7/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? The solution I think is to get rid of the build.sh/build.bat wrappers and fix the ant scripts... I guess the primary job of these scripts is to setup the classpath correctly. We can get of them under assumption that everyone has a cpptasks (which is needed for native code compilation) and antcontrib packages installed with the Ant. Thanks, Andrey. I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrey Chernyshev Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Andrey Chernyshev wrote: On 7/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Rana Dasgupta wrote: Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? The solution I think is to get rid of the build.sh/build.bat wrappers and fix the ant scripts... I guess the primary job of these scripts is to setup the classpath correctly. We can get of them under assumption that everyone has a cpptasks (which is needed for native code compilation) and antcontrib packages installed with the Ant. And as soon as we get rid of the need for cpptasks ;) I wonder if we can add them to the classpath in the first ant-script we run, and then have them avail for invoked scripts. Then the only assumptions we make are having and and java in place, and the rest simple works. geir Thanks, Andrey. I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
--- Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
[SNIP]
I guess the primary job of these scripts is to
setup the classpath
correctly.
We can get of them under assumption that everyone
has a cpptasks
(which is needed for native code compilation) and
antcontrib packages
installed with the Ant.
And as soon as we get rid of the need for
cpptasks ;)
I wonder if we can add them to the classpath in the
first ant-script we
run, and then have them avail for invoked scripts.
Seriously, if the native build is switched to a make
approach, it wouldn't be impossible to remove the ac
dependency from what I can see in the drlvm buildfile.
Personally I would probably prefer the cpptasks be
used but grudgingly admit that actual C hackers are
probably more accustomed to make. ;)
Beyond that, however, antcontrib is THE most often
mentioned/recommended 3rd-party package on Ant's user
lists; more than one of its developers are also Ant
committers. I don't know that I see the harm in
simply requiring that the user install antcontrib (and
cpptasks, while it is used). The user can simply drop
the jars into $ANT_HOME/lib (actually I don't set
ANT_HOME but let the location of the invoker script
along my PATH pick it up, but that's a different
story). On shared installations (with Ant = 1.6),
the user can install in ${user.home}/.ant/lib or
supply the -lib option at the commandline. If the
-lib option is chosen, that can be configured with
ANT_ARGS . My cygwin Harmony classpath build
environment actually uses the -lib option to include
the ecj jar, for example.
/rambling
-Matt
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 7/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Question: Should the above be bundled up as a JIRA patch? I think the goal should be allowing people interested in this mode to simply pass a sensible flag/property, such that for everyone else, there is no change. And no - you're a committer, so you can apply it. But please, make this one-off condition something that you trigger w/ a flag passed to build.bat/.sh (until we get rid of it), rather than something everyone has to deal with. Will do. I need to get a better understanding of the rather complex build system. I plan to hold off until after I do a few MMTk related commits first. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++ build.bat (working copy)
@@ -138,7 +138,7 @@
)
REM Note: vm.jitrino is always complied in release mode, otherwise it makes VM
debug too slow
-CALL %ANT_COMMAND% -f make/build.xml -Dvm.jitrino.cfg=release %*
+CALL %ANT_COMMAND% -f make/build.xml %*
GOTO THEEND
Mods to drlvm/trunk/build/make/components/vm/jitrino.xml
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
For some unknown reason, svn diff wants to report that every line has
changed in common_vm.xml. Probably something to do with carriage
return line feed. In any case the mods to
drlvm/trunk/build/make/targets/common_vm.xml. These are the same mods
that were reported in the email titled, [DRLVM] questions about
build.bat -DEBUILD_CFG=debug -DCXX=msvc. They are repeated here for
completeness:
- select os=win cxx=msvc
compilerarg value=/Od /
compilerarg value=/MTd /
compilerarg value=/D_DEBUG /
/select
A new svn update of both classlib and drlvm was downloaded this
morning. The above mods were applied. And, finally, a build.bat
-DEBUILD_CFG=debug -DCXX=msvc was run. The binary is now debuggable
with MS Visual Studio.
Question: Should the above be bundled up as a JIRA patch?
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 7/13/06, Rana Dasgupta [EMAIL PROTECTED] wrote: Weldon, Thanks. If jitrino building in debug mode was switched off to not make it crawl, is it an option to not apply these mods, but just leave this thread as a reference for people who need this? Yes, of course. These mods are most relevant to debugging the write barrier, vmmagic, inlined object allocation kinds of functions. Once they are up and going, we probably won't use these build options. I am somehow being able to debug just fine with devenv ( but I don't use jitrino symbols ) without any change to common_vm.xml. This is good. Given a stable JIT, debugging VM code is basically orthogonal to the compiler. It is only stuff like stepping through write barrier generation and vmmagic where jitrino symbols come in handy. The rest of the time it makes sense to build the JIT in full optimize mode and the rest of DRLVM in debug mode when debugging VM code. Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On the 0x1A6 day of Apache Harmony Weldon Washburn wrote:
All,
The following build mods will create a drlvm binary that can be used
to debug the Jitrino.JET write barriers. Rather than make everyone
suffer through long email chains, Alex and I collaborated offline.
Great! Good feature for JIT hackers!
Though, I would prefer to leave an option directly in SVN sources.
-Dvm.jitrino.cfg=debug -- for debug build
-Dvm.jitrino.cfg=release -- for most people (the default)
is that possible?
BTW, build.sh needs update too (I prefer to build on Linux:)
The mods to drlvm/trunk/build/build.bat:
--- build.bat (revision 421403)
+++ build.bat (working copy)
@@ -138,7 +138,7 @@
)
REM Note: vm.jitrino is always complied in release mode, otherwise it makes
VM
debug too slow
-CALL %ANT_COMMAND% -f make/build.xml -Dvm.jitrino.cfg=release %*
+CALL %ANT_COMMAND% -f make/build.xml %*
GOTO THEEND
Mods to drlvm/trunk/build/make/components/vm/jitrino.xml
project name=vm.jitrino
-target name=init
+target name=init depends=common_vm
property name=build.depends
value=extra.apr,vm.vmcore,vm.encoder /
property name=outtype value=shared /
property name=libname value=jitrino /
@@ -48,7 +48,8 @@
patternset id=java.classes.pattern includes=empty_pattern/
!-- the compiler doesn't extend common compiler --
-compiler name=${build.cxx} id=cpp.compiler
+!-- compiler name=${build.cxx} id=cpp.compiler --
+compiler id=cpp.compiler extends=common.cpp.compiler
For some unknown reason, svn diff wants to report that every line has
changed in common_vm.xml. Probably something to do with carriage
return line feed. In any case the mods to
drlvm/trunk/build/make/targets/common_vm.xml. These are the same mods
that were reported in the email titled, [DRLVM] questions about
build.bat -DEBUILD_CFG=debug -DCXX=msvc. They are repeated here for
completeness:
- select os=win cxx=msvc
compilerarg value=/Od /
compilerarg value=/MTd /
compilerarg value=/D_DEBUG /
/select
A new svn update of both classlib and drlvm was downloaded this
morning. The above mods were applied. And, finally, a build.bat
-DEBUILD_CFG=debug -DCXX=msvc was run. The binary is now debuggable
with MS Visual Studio.
Question: Should the above be bundled up as a JIRA patch?
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
On 14 Jul 2006 09:47:14 +0700, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x1A6 day of Apache Harmony Weldon Washburn wrote: All, The following build mods will create a drlvm binary that can be used to debug the Jitrino.JET write barriers. Rather than make everyone suffer through long email chains, Alex and I collaborated offline. Great! Good feature for JIT hackers! Though, I would prefer to leave an option directly in SVN sources. -Dvm.jitrino.cfg=debug -- for debug build -Dvm.jitrino.cfg=release -- for most people (the default) is that possible? Actually I did not think of trying -Dvm.jitrino.cfg=debug. Maybe it will work. BTW, build.sh needs update too (I prefer to build on Linux:) I am hoping someone will volunteer to try the linux build and figure out what needs to be changed. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
