[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic