You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/07/14 01:16:16 UTC
[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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Matt Benson <gu...@yahoo.com>.
--- Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> Matt Benson wrote:
> > --- Geir Magnusson Jr <ge...@pobox.com> 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?
ant-contrib contains programming concepts that are at
odds with Ant's fundamental design. e.g. 1 <if> vs.
<target depends if/unless>. e.g. 2 <for/foreach> vs.
Java-implemented tasks using <fileset> or other types.
<var> specifically exists to defeat Ant's concept of
property immutability. For the most part one can get
by without ant-contrib, but in a realistic world,
sometimes it's just easiest to use it. Some of the
other ant-contrib tasks just might be considered too
specialized for Ant core. Ant's own distribution
contains many things it shouldn't as it is; future
versions will be looking to streamline by moving many
of what are optional tasks today to antlibs that can
be used optionally.
>
> > 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...
>
I guess that was kind of my point wrt ant-contrib
being as commonly used as it is. You never know what
other project will be relying on it; one might
therefore consider it to be a "standard extension," as
it were.
> >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...
Ant's SVN HEAD contains a <classloader> task that can
do some of these things. I'm not sure who uses it; I
don't. It's been in HEAD and marked as experimental
for some years now; it may well ship with 1.7 . I'll
see what info I can dig up on this task.
>
> > 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?
>
You could, by forking Ant. Ant doesn't provide <ant
fork="true">, however. One would have to configure
the <java> task. The problem has been that nobody
sees fit to keep track of the various cmdline options
to forking Ant in code. This might actually make a
decent antlib, however, as keeping such code in one
isolated place would be easier. I'll have to keep
this in mind...
-Matt
> geir
>
>
>
---------------------------------------------------------------------
> Terms of use :
> http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail:
> harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
>
>
__________________________________________________
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the
Jitrino.JET write barrier patch
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Matt Benson wrote:
> --- Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Matt Benson <gu...@yahoo.com>.
--- Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the
Jitrino.JET write barrier patch
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Andrey Chernyshev wrote:
> On 7/14/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Andrey Chernyshev <a....@gmail.com>.
On 7/14/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrey Chernyshev
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the
Jitrino.JET write barrier patch
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Weldon Washburn <we...@gmail.com>.
On 7/13/06, Rana Dasgupta <rd...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Rana Dasgupta <rd...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Weldon Washburn <we...@gmail.com>.
On 14 Jul 2006 09:47:14 +0700, Egor Pasko <eg...@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Egor Pasko <eg...@gmail.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the Jitrino.JET write barrier patch
Posted by Weldon Washburn <we...@gmail.com>.
On 7/14/06, Geir Magnusson Jr <ge...@pobox.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM] build fixes that allow normal single step debug of the
Jitrino.JET write barrier patch
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org