[RFC] Introduce BreakAtCompileId
Leslie Zhai
zhaixiang at loongson.cn
Tue Nov 10 08:21:23 UTC 2020
Hi Liu,
Thanks for your kind response!
在 2020年11月10日 15:49, Liu, Xin 写道:
> 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.
Thanks for your information about JDK-8255216. We are debugging the C2
and disabled C1 compiler for some cpu. So perhaps it doesn't need to
consider about the break at OSR or sort of things. Please point out my
fault :)
>
> 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?
Ao Qi, our leader, suggested me to request for comments about the
BreakAtC2CompileId. Actually `BreakAtCompileId` is not precise. And in
the very beginning, java -Xcomp -XX:+OptoBreakpoint -version, it was
able to debug the first, second, less than 10 compiler_id methods for C2
compiler. But after fixed several bugs, and specially it is not able to
use `handle SIGSEGV nostop noprint` due to some NullCheck related bugs.
So I introduced the `BreakAtCompileId` for inner debugging purpose.
Sorry that we are so busy about debugging the execute thread for C2
compiler. So that is all the information I could share.
Thanks,
Leslie Zhai
>
> 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