6953477: review request for portability improvements to Hotspot

[Tom Rodriguez]

On Aug 2, 2010, at 4:57 PM, David Holmes wrote:

> Tom Rodriguez said the following on 08/03/10 06:45:
>> On Jul 29, 2010, at 7:36 PM, David Holmes wrote:
>>> Tom Rodriguez said the following on 07/30/10 03:18:
>>>> You should make equivalent changes in os_windows_x86.cpp too.
>>> Ideally yes, but at the time, as now, I had no access to Windows boxes for building or testing this.
>> jprt always builds windows and I'm not sure how much testing this needs.  The print_location code itself is platform dependent and as long as the code compiles it seems like it should work.
> 
> Building via jprt is hardly an effective development process.

In general sure but it would be good enough for this I think.

> 
>>> Registers:
>>> r0  = 0x000b0c00
>>> r1  = 0x00006b70
>>> r2  = 0x00000000
>>> r3  = 0x00000064
>>> r4  = 0x00000000
>>> r5  = 0x000b0c00
>>> r6  = 0x000b0c00
>>> r7  = 0x00021400
>>> r8  = 0x00020638
>>> r9  = 0x4a650c58
>>> r10 = 0x00000000
>>> fp  = 0x406fcad4
>>> r12 = 0x00000001
>>> sp  = 0x406fca58
>>> lr  = 0x403e1768
>>> pc  = 0x40480278
>>> 
>>> 
>>> Register to memory mapping:
>>> r0  = 0x000b0c00
>>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
>>>  java.lang.Thread.State: RUNNABLE
>> This is pretty verbose since we print the register values twice.  
> > Why not just print them once by losing the first section?
> 
> Because it is entirely possible that attempting to print some information about a register value will induce a secondary crash. This way you at least get the original set of crash registers reported.

Oh right, good point.

> 
> I use a newline to start the printing because I don't know how the individual print routines will format things. The current approach should at least make it clear where the boundaries are.

Fair enough.

tom

> 
> David
> -----
> 
>  The lack of indenting makes it less readable too though that's harder to fix without modifing every print_on routines which I'm not sure we want to do.  Maybe the printing should just start on the same line instead of having a cr in between.  Printing nothing for unknown values might make sense too.
>> tom
>>> r1  = 0x00006b70
>>> 0x00006b70 is pointing to unknown location
>>> r2  = 0x00000000
>>> 0x00000000 is pointing to unknown location
>>> r3  = 0x00000064
>>> 0x00000064 is pointing to unknown location
>>> r4  = 0x00000000
>>> 0x00000000 is pointing to unknown location
>>> r5  = 0x000b0c00
>>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
>>>  java.lang.Thread.State: RUNNABLE
>>> r6  = 0x000b0c00
>>> "Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
>>>  java.lang.Thread.State: RUNNABLE
>>> r7  = 0x00021400
>>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
>>>  java.lang.Thread.State: RUNNABLE
>>> r8  = 0x00020638
>>> 0x00020638 is pointing to unknown location
>>> r9  = 0x4a650c58
>>> {method}
>>> - klass: {other class}
>>> r10 = 0x00000000
>>> 0x00000000 is pointing to unknown location
>>> fp  = 0x406fcad4
>>> 0x406fcad4 is pointing into the stack for thread: 0x00021400
>>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
>>>  java.lang.Thread.State: RUNNABLE
>>> r12 = 0x00000001
>>> 0x00000001 is pointing to unknown location
>>> sp  = 0x406fca58
>>> 0x406fca58 is pointing into the stack for thread: 0x00021400
>>> "main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
>>>  java.lang.Thread.State: RUNNABLE
>>> lr  = 0x403e1768
>>> 0x403e1768: JVM_StartThread+0xe8 in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000
>>> pc  = 0x40480278
>>> 0x40480278: <offset 0x2ef278> in /java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so at 0x40191000