open jdk debug options

[Cong Wang]

OK. So, Neo, the option for -ggdb3 is for sun cc or gcc?
Thank you all for your response so far.
Regards
James Wang

On Wed, Oct 8, 2008 at 1:08 PM, Neo Jia <neojia at gmail.com> wrote:
> On Tue, Oct 7, 2008 at 10:05 PM, Jon Masamitsu <Jon.Masamitsu at sun.com> wrote:
>>
>> When you start
>>
>> dbx java
>>
>> you are starting dbx on the java launcher.  The
>> launcher does an exec of the VM.
>> In the output below from dbx the "stopped in main"
>> indicates that the exec has happened and  you've
>> stopped in the main of the VM.  At that point
>> dbx has forgotten about the breakpoints you've
>> set because it thinks the breakpoints are in the
>> launcher.
>
> FYI. gdb can keep follow the exec after 6.5.
>
> Thanks,
> Neo
>
>>
>> You need to set your LD_LIBRARY_PATH
>> to point to the libjvm.so that you've built.
>>
>> Compile this program
>>
>> public class PrintLibraryPath {
>>   public static void main(String[] args) {
>>      System.out.println(System.getProperty("java.library.path"));
>>   }
>> }
>>
>> and execute it with the java you want to debug.
>>
>> I have /usr/jdk/jdk1.5.0_11/bin/java so
>>
>> -------------------
>> /usr/jdk/jdk1.5.0_11/bin/java PrintLibraryPath
>> /usr/jdk/instances/jdk1.5.0/jre/lib/sparc/server:/usr/jdk/instances/jdk1.5.0/jre/lib/sparc:/usr/jdk/instances/jdk1.5.0/jre/../lib/sparc:/usr/lib
>> -------------------
>>
>> prints the LD_LIBRARY_PATH for /usr/jdk/jdk1.5.0_11/bin/java
>>
>> Set your LD_LIBRARY_PATH accordingly.
>>
>> Then start dbx on java and you should see something like
>>
>> -------------------
>> dbx /usr/jdk/jdk1.5.0_11/bin/java
>> For information about new features see `help changes'
>> To remove this message, put `dbxenv suppress_startup_message 7.5' in your
>> .dbxrcReading java
>> Reading ld.so.1
>> Reading libthread.so.1
>> Reading libdl.so.1
>> Reading libc.so.1
>> -------------------
>>
>> Run with -version
>>
>> -------------------
>>
>> dbx: run -version
>> Running: java -version
>> (process id 6309)
>> Reading libc_psr.so.1
>> Reading libjvm.so
>> Reading libsocket.so.1
>> Reading libsched.so.1
>> Reading libCrun.so.1
>> Reading libm.so.1
>> Reading libnsl.so.1
>> Reading libm.so.2
>> Reading libscf.so.1
>> Reading libdoor.so.1
>> Reading libuutil.so.1
>> Reading libmd5.so.1
>> Reading libmd5_psr.so.1
>> Reading libmp.so.2
>> Reading libhpi.so
>> Reading libverify.so
>> Reading libjava.so
>> Reading libzip.so
>> java version "1.5.0_11"
>> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
>> Java HotSpot(TM) Server VM (build 1.5.0_11-b03, mixed mode)
>>
>> execution completed, exit code is 0
>> dbx:
>> -------------------
>>
>> Running with -version causes the VM to execute and all the
>> libraries get loaded.  You should them see your
>>
>> /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so
>>
>> You should be able to set your breakpoints now and run
>> with your real java command line.
>>
>>
>> Cong Wang wrote:
>>>
>>> Hi Jon:
>>>    I went into the  ALT_OUTPUTDIR/bin
>>> start dbx with :
>>> dbx java
>>> For information about new features see `help changes'
>>> To remove this message, put `dbxenv suppress_startup_message 7.6' in your
>>> .dbxrc
>>> Reading java
>>> Reading /usr/lib/ld.so.1
>>> Reading /lib/libthread.so.1
>>> Reading /scratch/wang/java_tm_7/lib/sparc/jli/libjli.so
>>> Reading /lib/libdl.so.1
>>> Reading /lib/libc.so.1
>>>
>>> then I map the src file foler into the current folder, using pathmap
>>>
>>> pathmap /scratch/wang/openjdk/hotspot/src/cpu/sparc/vm
>>> /scratch/wang/java_tm_7/bin
>>>
>>> after the pathmap, I try to find the function using
>>>
>>> whereis compiler_lock_object
>>>
>>> there is no output.
>>>
>>> But I know that function is in
>>> /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so, therefore
>>> I use the following to load the shared library:
>>> loadobject -load /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so
>>> Reading /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so
>>> Loaded loadobject: /scratch/wang/java_tm_7/lib/sparc/server/libjvm.so
>>>
>>> now, when I use whereis to find compiler_lock_object, I got:
>>>  whereis compiler_lock_object
>>> function:
>>>
>>> `/scratch/wang/java_tm_7/lib/sparc/server/libjvm.so`assembler_sparc.cpp`#__1cOMacroAssemblerUcompiler_lock_object6MpnMRegisterImpl_222pnVBiasedLockingCounters__v_
>>>     [non -g, demangles to:
>>>
>>> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)]
>>>
>>> Then, I set a break point using:
>>> stop in compiler_lock_object
>>> dbx: warning: 'compiler_lock_object' has no debugger info -- will
>>> trigger on first instruction
>>> (2) stop in
>>> MacroAssembler::compiler_lock_object(RegisterImpl*,RegisterImpl*,RegisterImpl*,RegisterImpl*,BiasedLockingCounters*)
>>>
>>>
>>> So, I run my application in the debugger
>>> using:
>>>
>>> run -server -Xcomp -Xbatch -Xss128k -XX:NewSize=256m -Xnoclassgc
>>> -verbose:gc -classpath /scratch/wang/java_tm_7/bin/
>>> SynchronizedCounter
>>>
>>> (process id 25142)
>>> dbx: process 25142 about to exec("/scratch/wang/java_tm_7/bin/java")
>>> dbx: program "/scratch/wang/java_tm_7/bin/java" just exec'ed
>>> dbx: to go back to the original program use "debug $oprog"
>>> t at 1 (l at 1) stopped in main at 0x00010d30
>>> 0x00010d30: main       :        save     %sp, -128, %sp
>>>
>>> (dbx) cont
>>> t at 2 (l at 2) signal SEGV (no mapping at the fault address) in (unknown)
>>> at 0xfc063710
>>> 0xfc063710:     ld       [%o0 + 4], %l0
>>> Current function is jni_invoke_nonstatic (optimized)
>>>  1084     JavaCalls::call(result, method, &java_args, CHECK);
>>>
>>> I will never get to my break point. But if I run this outside dbx,
>>> everything works fine.
>>>
>>> SynchronizedCounter is a small multi-threaed java program I wrote to
>>> test the jvm. It has two threads try to grab a lock and increment a
>>> shared counter.
>>> It works fine but I want to change how the jvm manages the lock, so I
>>> want to stop the program when jvm creates a lock and acquires it.
>>>
>>> Thanks for any comment you may have in advance.
>>>
>>> Regards
>>> James Wang
>>>
>>>
>>> On Tue, Oct 7, 2008 at 10:03 PM, Jon Masamitsu <Jon.Masamitsu at sun.com>
>>> wrote:
>>>
>>>>
>>>> How do you start dbx on java?  And what is dbx saying
>>>> exactly?
>>>>
>>>> Cong Wang wrote:
>>>>
>>>>>
>>>>> Hi all:
>>>>>  I am trying to modify some part of the hotspot runtime interpreter
>>>>> and I would like to debug that using either dbx or gdb. I have compile
>>>>> the file using the following options:
>>>>>
>>>>> ALT_BINARY_PLUGS_PATH=/scratch/wang/openjdk-binary-plugs
>>>>> ALT_FREETYPE_LIB_PATH=/usr/local/lib
>>>>> ALT_FREETYPE_HEADERS_PATH=/usr/local/include
>>>>> ALT_CUPS_HEADERS_PATH=/scratch/wang/cups-1.3.8
>>>>> ANT_HOME=/usr/sfw
>>>>> ALT_OUTPUTDIR=/scratch/wang/java_tm_7
>>>>> DEV_ONLY=true
>>>>> DEBUG=true
>>>>>
>>>>>   I am not able to use dbx to debug java in the ALT_OUTPUTDIR/bin
>>>>> directory. I would like to set a break point at
>>>>> hotspot/src/cpu/sparc/vm/assembler_sparc.cpp
>>>>> MacroAssembler::compiler_lock_object function. I have tried to use the
>>>>> dbx pathmap command but it doesn't seem to help dbx to locate the
>>>>> source file or the function definition.
>>>>>  Any suggestions? Thanks in advance for any comment.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> I would remember that if researchers were not ambitious
> probably today we haven't the technology we are using!
>



-- 
Regards
James Wang