[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    JIT debugging (Attach and speed)
From:       Yichao Yu <yyc1992 () gmail ! com>
Date:       2016-03-22 14:55:57
Message-ID: CAMvDr+TKDYeECiUK7Kz7TGSRF826Vq24z_=CPQXz1vyxmMUm_w () mail ! gmail ! com
[Download RAW message or body]

Hi,

I've recently seen some issues when debugging julia JIT code with GDB.
Some of these might worth a bug report but I'd like to post here first
since the most blocking issue was discussed here a few years ago.

1. Registering JIT code to GDB is O(n^2) and this is very bad for
serious JIT users like julia. (I've seen 10k to 100k jit objects
generated in the test)

   The issue was discussed on this list ~2011[1] but it seems that the
issue is still there. I was also told that lldb 3.8 should support the
same JIT debugging interface without the O(n^2) slow down[2].

2. JIT code registration on attach is broken.

    When I set a breakpoint on `jit_inferior_init`[3] (i.e. lauching
gdb with `gdb --args gdb -p <pid_to_debug>`) which IIUC is what
responsible for walking the jit object list at init time, it seems
that the function is never called.

    (I haven't seen a bug report about this yet)

3. (minor) Reading debug info from JIT object file generates read of large size.

   This triggers an assertion in rr[4]. It's arguably rr's fault to
assume a upper limit on the read request size (fixed now) but since
this doesn't happen otherwise I'd just like to point this out in case
some optimization is needed here.

[1] https://sourceware.org/ml/gdb/2011-01/msg00002.html
[2] https://github.com/JuliaLang/julia/issues/14846#issuecomment-176902134
[3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/jit.c;h=afc1c517fa745582bd198601e46a77af72114017;hb=HEAD#l1323
 [4] https://github.com/mozilla/rr/issues/1665#issuecomment-192983671


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic