On the 0x1F2 day of Apache Harmony Armand Navabi wrote:
> This did not seem to solve the problem. It does not successfully put a
> break in main.c (says no source file main.c).
Oops, some day I made everything build in debug mode locally. And
forgot about it. Currently there is no option for that. TBD,
obviously. I do it with the patch (linux only) like this:
Index: working_vm/build/build.sh
===================================================================
--- working_vm/build/build.sh (revision 449589)
+++ working_vm/build/build.sh (working copy)
@@ -80,6 +80,6 @@
# it is necessarily to compile 'vm.jitrino' in release mode
-$ANT_COMMAND -f ./make/build.xml -Dvm.jitrino.cfg=release "$@" || ERROR
+$ANT_COMMAND -f ./make/build.xml "$@" || ERROR
Index: working_vm/build/make/components/vm/jitrino.xml
===================================================================
--- working_vm/build/make/components/vm/jitrino.xml (revision 449589)
+++ working_vm/build/make/components/vm/jitrino.xml (working copy)
@@ -25,7 +25,7 @@
-->
<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" />
@@ -50,7 +50,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">
<fileset dir="${src}">
<include name="dynopt/*.cpp" />
<include name="main/*.cpp" />
Index: working_vm/build/make/targets/common_vm.xml
===================================================================
--- working_vm/build/make/targets/common_vm.xml (revision 449589)
+++ working_vm/build/make/targets/common_vm.xml (working copy)
@@ -105,6 +105,8 @@
<select cfg="debug">
<compilerarg value="-O0" />
+ <compilerarg value="-g" />
+ <compilerarg value="-ggdb3" />
</select>
</select>
Index: working_classlib/depends/build/makefile.include
===================================================================
--- working_classlib/depends/build/makefile.include (revision 448846)
+++ working_classlib/depends/build/makefile.include (working copy)
@@ -28,5 +28,5 @@
DLLPATH=$(HY_HDK)/jdk/jre/bin/
SHAREDSUB=../shared/
-CFLAGS = -O1 $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \
+CFLAGS = -O0 -g $(HY_CFLAGS) -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT \
-D$(HY_ARCH_DEFINE) $(VMDEBUG) -I$(HY_HDK)/include
-I$(HY_HDK)/jdk/include -I. -I$(SHAREDSUB)
Guys, I hope someone finishes that into a final solution so we can put
that to SVN. Most likely, I'll do that, when I am done with fixing
Jitrino.OPT to run the ClassLoaderTest. Any volunteering is, as
always, welcome))
> [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $ gdb
> ./java
> GNU gdb 6.4
> Copyright 2005 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
> library "/lib/libthread_db.so.1".
>
> (gdb) break main.c:360
> No source file named main.c.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb) show environment
>
> ...
> LD_LIBRARY_PATH=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/default/
> ...
> JAVA_HOME=/homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre
> ...
>
>
> I am able to do "break main", but I tried to do what you have explained
> below (i.e. break somewhere after libjitrino.so is loaded), but it says
> compile_jit_a_method is not defined.
Thank you for digging into it. That's really valuable. I hope we will
fix the issue soon.
> Thanks,
> Armand
>
> Egor Pasko wrote:
> > I solve this by breaking inside launcher after VM lib is loaded, then
> > I break somewhere after libjitrino.so is loaded. Then I can break
> > anywhere :)
> >
> > looks like this:
> > break main.c:360
> > r
> > dis
> > break compile_jit_a_method
> > c
> > dis
> > break whatever function you want
> >
> > You can make it a script via GDB's 'define' and put somewhere in
> > ~/.gdbinit, two scripts are better: first for initial run, the second
> > script does the same but reusing old breakpoint numbers:
> > dis
> > en 1
> > r
> > dis
> > en 2
> > c
> > dis
> >
> > I should put that into the FAQ, obviously.
> >
> >
> >> And then when I run the program it never stops at the breakpoint, though I
> >> see the print I have inserted in the code. Secondly, and more importantly,
> >> if I try to do anything interesting, like run helloworld, gdb seems to lose
> >> a thread and then hang (says it Cannot find a thread. Invalid thread
> >> handle). I have to then stop it and go kill it.
> >>
> >
> > this one is probably a separate issue (not connected with "future
> > shared library load"). Try my above suggestion, please.
> >
> >
> >> GNU gdb 6.4
> >> Copyright 2005 Free Software Foundation, Inc.
> >> GDB is free software, covered by the GNU General Public License, and you
> >> are
> >> welcome to change it and/or distribute copies of it under certain
> >> conditions.
> >> Type "show copying" to see the conditions.
> >> There is absolutely no warranty for GDB. Type "show warranty" for details.
> >> This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
> >> library "/lib/libthread_db.so.1".
> >>
> >> (gdb) r helloworld
> >> Starting program:
> >> /u/u12/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/java
> >> helloworld
> >> [Thread debugging using libthread_db enabled]
> >> [New Thread 16384 (LWP 11007)]
> >> [New Thread 32769 (LWP 11010)]
> >> [New Thread 16386 (LWP 11011)]
> >> Cannot find thread 32769: invalid thread handle
> >> (gdb) q
> >> The program is running. Exit anyway? (y or n) y
> >>
> >> [1]+ Stopped gdb ./java
> >>
> >>
> >> Thanks,
> >> Armand
> >>
> >>
> >> On the 0x1F0 day of Apache Harmony Armand Navabi wrote:
> >>
> >>>> When I try to run ./java helloworld, it just hangs and I have to kill
> >>>> the process. I investigated this a little bit, and I found that it
> >>>> hangs on the call to FindClass (in main.c line around line 1199).
> >>>> I am
> >>>> unable debug with gdb also, so I have resorted to printf's, and in
> >>>> jni.cpp, I found the definition of FindClass, and put an printf to see
> >>>> what class it is trying to find when it hangs. I see the following:
> >>>>
> >>>> Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread
> >>>>
> >>>> Also, when I run ./java -Xtrace:em, I get the following (and it
> >>>> hangs):
> >>>> ...
> >>>> EM: compile start:[JET_DPGO n=802] java/lang/Thread::join()V
> >>>> EM: compile done:[JET_DPGO n=802: OK] java/lang/Thread::join()V
> >>>> EM: compile start:[JET_DPGO n=803] java/lang/Object::wait()V
> >>>> EM: compile done:[JET_DPGO n=803: OK] java/lang/Object::wait()V
> >>>> Line 478 in jni.cpp: inside JNICALL FindClass: java/lang/Thread
> >>>>
> >>>> Again, it seems to always hang after FindClass is called for
> >>>> java/lang/Thread.
> >>>>
> >>>> I have tried setting LD_LIBRARY_PATH as suggested earlier. I also
> >>>> have
> >>>> JAVA_HOME set (and I have tried it with it unset). Everything
> >>>> seems to
> >>>> have the same behavior.
> >>>> [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $
> >>>> echo
> >>>> $LD_LIBRARY_PATH
> >>>> /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/:/
> >>>> homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin/
> >>>> default
> >>>> [EMAIL PROTECTED] ~/Harmony/enhanced/drlvm/trunk/build/deploy/jre/bin $
> >>>> echo
> >>>> $JAVA_HOME
> >>>> /homes/anavabi/Harmony/enhanced/drlvm/trunk/build/deploy/jre
> >>>>
> >>>> I am using Gentoo Linux. Any ideas?
> >>>>
> >>>> Thanks,
> >>>> Armand
> >>>>
> >>>> Gregory Shimansky wrote:
> >>>>
> >>>>> On Friday 22 September 2006 14:31 Egor Pasko wrote:
> >>>>>
> >>>>>
> >>>>>> what makes me really nervous is that I cannot debug in GDB on Linux
> >>>>>> (!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!)
> >>>>>>
> >>>>>> When GDB starts, it becomes broken right after the start:
> >>>>>> [New Thread 1080397952 (LWP 13879)]
> >>>>>> [New Thread 1083603888 (LWP 13882)]
> >>>>>> Cannot find user-level thread for LWP 13879: generic error
> >>>>>>
> >>>>>> Did anybody come across this problem recently? I googled a
> >>>>>> little, but
> >>>>>> could not find any valuable comments. I remember, there was no such
> >>>>>> problem in older days!! Is that our new ThreadManager that does
> >>>>>> things
> >>>>>> like this? or is it something else?
> >>>>>>
> >>>>>>
> >>>>> I've seen in another thread. The problem with gdb is caused
> >>>>> because process
> >>>>> reexecs itself with new environment (there is no other way known
> >>>>> to tell
> >>>>> dynamic linker to use a library path). This is new launcher
> >>>>> feature necessary
> >>>>> to get rid of java shell script and use a real executable.
> >>>>>
> >>>>> Ivan Volosyuk investigated the conditions when launcher performs
> >>>>> execing
> >>>>> itself to set LD_LIBRARY_PATH and it appears (unless fixed
> >>>>> recently) that you
> >>>>> need to set LD_LIBRARY_PATH=<HDK path>/bin/:<HDK path>/bin/
> >>>>> default. Don't
> >>>>> forget a tailing slash in the first path :)
> >>>>>
> >>>>> Anyway, to get the correct LD_LIBRARY_PATH which launcher wants
> >>>>> you can get it
> >>>>> from /proc/`pidof java`/environ if you launch a simple java
> >>>>> program and catch
> >>>>> its reexeced environment. If LD_LIBRARY_PATH contents is equal to
> >>>>> what
> >>>>> launcher wants, reexecing doesn't happen and this allows normal
> >>>>> debugging.
> >>>>>
> >>>>> I think we should document this since it is going to stay for a
> >>>>> long time and
> >>>>> is really required for development on Linux.
> >>>>>
> >>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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]
> >>>
> >>>
> >>>
> >> --
> >> 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]
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
>
>
--
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]
