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

List:       gdb
Subject:    Re: JIT code debugging doesn't work with dynamically linked LLVM
From:       Yichao Yu <yyc1992 () gmail ! com>
Date:       2016-09-25 1:48:20
Message-ID: CAMvDr+RzwHjtjKrFp1WcrJbmVSwUJwa-pe2Y72YT6+1XqeMXZg () mail ! gmail ! com
[Download RAW message or body]

On Mon, Sep 19, 2016 at 11:51 AM, Yichao Yu <yyc1992@gmail.com> wrote:
> The symptom is that when we switch to dynamically linked LLVM (shared
> library, instead of static library), the JIT code debugging doesn't
> work anymore.


I've posted here since I somehow thought the mailing list is used for
bug tracking. I've just realized / remembered that there's an actual
bug tracker so I've posted it there instead.

https://sourceware.org/bugzilla/show_bug.cgi?id=20633

>
> I've just traced down the issue to this piece of code in
> `jit_breakpoint_re_set_internal`
>
> ```
>       reg_symbol = lookup_minimal_symbol_and_objfile (jit_break_name);
>       if (reg_symbol.minsym == NULL
>       || BMSYMBOL_VALUE_ADDRESS (reg_symbol) == 0)
>     return 1;
>
>       desc_symbol = lookup_minimal_symbol (jit_descriptor_name, NULL,
>                        reg_symbol.objfile);
>       if (desc_symbol.minsym == NULL
>       || BMSYMBOL_VALUE_ADDRESS (desc_symbol) == 0)
>     return 1;
> ```
>
> The issue is that `lookup_minimal_symbol_and_objfile (jit_break_name)`
> returns the plt entry in our code that links to LLVM so obviously the
> lookup for the desc_symbol cannot success since there's no plt entry
> for it..... (and even if it does, the breakpoint is still set on the
> wrong function)
>
> This can probably be fixed by skipping plt entries in the first symbol
> lookup (no patch attached since I don't know how to do that in gdb).
> It might also be nice if multiple symbols presented in different
> libraries can be supported to.
>
> Yichao Yu

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