[RFC] Introduce BreakAtCompileId
Liu, Xin
xxinliu at amazon.com
Tue Nov 10 07:49:12 UTC 2020
Hi, Leslie,
Actually, there're 2 compile_id-specific flags -- CIBreakAt and CIBreakAtOSR in global.hpp
They are now not in use due to JDK-8255216. In my understanding, compiler driver simply ignores them.
If they are in effect, I believe you should stop at both compiler-and-run-time.
May I know what's the meaning of RFC in the subject? Are you proposing a new feature?
I've seen some RFC emails in hotspot maillists, but I am still not familiar with the formal process of a proposal. I know JEP, but it's more formal and for bigger project, right?
Would you mind sharing more information about the RFC process?
Thanks,
--lx
On 11/9/20, 10:10 PM, "hotspot-compiler-dev on behalf of Leslie Zhai" <hotspot-compiler-dev-retn at openjdk.java.net on behalf of zhaixiang at loongson.cn> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
在 2020年11月10日 12:45, Mikael Vidstedt 写道:
>
>> On Nov 9, 2020, at 5:31 PM, Leslie Zhai <zhaixiang at loongson.cn> wrote:
>>
>> Hi Mikael,
>>
>> Thanks for your teaching!
>>
>>
>> 在 2020年11月10日 06:24, Mikael Vidstedt 写道:
>>> Please take this to hotspot-dev-compiler if you want to continue the discussion.
>>>
>>>
>>> FWIW “continue” does take an argument, would that work for your use case?
>> Yes! It should work for my use case. It doesn't need to make the same wheel any more :)
>>
>>> (gdb) help continue
>>> Continue program being debugged, after signal or breakpoint.
>>> Usage: continue [N]
>>> If proceeding from breakpoint, a number N may be used as an argument,
>>> which means to set the ignore count of that breakpoint to N - 1 (so that
>>> the breakpoint won't break until the Nth time it is reached).
>> NullCheck also generated signal SIGSEGV:
>>
>>
>> 064 LD Rd, [Rt + #12 (8-bit)] @ indOffset8 # compressed ptr @ loadN ! Field: java/lang/String.value
>> 068 decode_heap_oop Rd, Rt @ decodeHeapOop
>> 070 MOV Rd, [Rt + #12 (8-bit)] @ indOffset8 @ loadRange
>> =>074 NullCheck Rd
>>
>>
>> It needs to press `c` when the base register is indeed NULL by comparing with other CPUs. So continue N -1 might not precise.
> Indeed. You may or may not be interested in another gdb command: handle SIGSEGV nostop noprint
But some NullCheck should not be NULL. So it couldn't echo `handle
SIGSEGV nostop noprint` >> ~/.gdbinit
I fixed a NullCheck related bug for C2 compiler this morning :)
Cheers,
Leslie Zhai
>
> There are of course pros and cons to ignoring that and other signals like it.
>
> Cheers,
> Mikael
>
>> Thanks,
>> Leslie Zhai
>>
>>> If non-stop mode is enabled, continue only the current thread,
>>> otherwise all the threads in the program are continued. To
>>> continue all stopped threads in non-stop mode, use the -a option.
>>> Specifying -a and an ignore count simultaneously is an error.
>>>
>>>
>>> Cheers,
>>> Mikael
>>>
>>>
>>>> On Nov 9, 2020, at 7:48 AM, Leslie Zhai <zhaixiang at loongson.cn> wrote:
>>>>
>>>> Hi,
>>>>
>>>> OptoBreakpoint is very useful for debugging C2 compiler when porting some cpu for jdk8u. It is able to `b breakpoint` for breaking at the prolog about for example Compile_id = 2. But when fixed several bugs for C2, it needs to press `c` times and times again for reaching the proper Compile_id.
>>>>
>>>> I `grep` Opto related options. But there is no such one to break at the precise Compile_id. Please teach me if there was :)
>>>>
>>>> So here comes BreakAtCompileId. It is able to break at the precise Compile_id which you want to debug.
>>>>
>>>>
>>>> gdb -ex=r --args $JAVA -Xcomp -XX:+PrintCompilation -XX:BreakAtCompileId=430 -version
>>>>
>>>>
>>>> (gdb) b breakpoint
>>>> Breakpoint 1 at 0x7ffff633b0d0: breakpoint. (133 locations)
>>>>
>>>> 6333 433 3 java.util.ImmutableCollections$List12::get (35 bytes) made not entrant
>>>>
>>>> Thread 2 "java" hit Breakpoint 1, 0x00007ffff711f410 in os::breakpoint() () at /home/zhaixiang/projects
>>>> 452 if (pslash != NULL) {
>>>> (gdb) si
>>>> 0x00007fffe01b46d1 in ?? ()
>>>> (gdb) x/22i $pc-44
>>>> 0x7fffe01b46a5: shl $0x3,%edx
>>>> 0x7fffe01b46a8: movabs $0x800000000,%r11
>>>> 0x7fffe01b46b2: add %r11,%r10
>>>> 0x7fffe01b46b5: cmp %r10,%rax
>>>> 0x7fffe01b46b8: jne 0x7fffd87cf920
>>>> 0x7fffe01b46be: nop
>>>> 0x7fffe01b46bf: nop
>>>> 0x7fffe01b46c0: mov %eax,-0x16000(%rsp)
>>>> 0x7fffe01b46c7: push %rbp
>>>> 0x7fffe01b46c8: sub $0x10,%rsp
>>>> 0x7fffe01b46cc: callq 0x7ffff711f410 <_ZN2os10breakpointEv>
>>>> => 0x7fffe01b46d1: mov 0xc(%rsi),%r11d
>>>> 0x7fffe01b46d5: mov 0x10(%rsi),%r10d
>>>> 0x7fffe01b46d9: cmp %r11d,%r10d
>>>> 0x7fffe01b46dc: je 0x7fffe01b46f6
>>>> 0x7fffe01b46de: mov $0x1,%eax
>>>> 0x7fffe01b46e3: add $0x10,%rsp
>>>> 0x7fffe01b46e7: pop %rbp
>>>> 0x7fffe01b46e8: cmp 0x128(%r15),%rsp
>>>> 0x7fffe01b46ef: ja 0x7fffe01b46fa
>>>> 0x7fffe01b46f5: retq
>>>> 0x7fffe01b46f6: xor %eax,%eax
>>>> (gdb) i r
>>>> rax 0x7fffe01b46c0 140736953272000
>>>> rbx 0x8004699e8 34364365288
>>>> rcx 0x1 1
>>>> rdx 0x7fffc5068980 140736498928000
>>>> rsi 0x62a020b40 26474580800
>>>> rdi 0x1 1
>>>> rbp 0x7ffff5a668d0 0x7ffff5a668d0
>>>> rsp 0x7ffff5a66290 0x7ffff5a66290
>>>> r8 0x80008eeb0 34360323760
>>>> r9 0x7ffb4cf60 34354810720
>>>> r10 0x800012488 34359813256
>>>> r11 0x800000000 34359738368
>>>> r12 0x0 0
>>>> r13 0x7292dae5 1922226917
>>>> r14 0x62a020818 26474579992
>>>> r15 0x7ffff00271e0 140737220080096
>>>> rip 0x7fffe01b46d1 0x7fffe01b46d1
>>>> eflags 0x206 [ PF IF ]
>>>> cs 0x33 51
>>>> ss 0x2b 43
>>>> ds 0x0 0
>>>> es 0x0 0
>>>> fs 0x0 0
>>>> gs 0x0 0
>>>>
>>>>
>>>> Thanks,
>>>> Leslie Zhai
>>>>
More information about the hotspot-compiler-dev
mailing list