6953477: review request for portability improvements to Hotspot

[David Holmes]

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.

>> 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.

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.

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
>