Re: JIT debugging (Attach and speed)

[Yichao Yu <yyc1992 at gmail dot com>]

>>
>> [1] https://sourceware.org/ml/gdb/2011-01/msg00009.html
>> [2] http://i.imgur.com/6Ca6Yal.jpg
>> [3] http://i.imgur.com/aHKGACX.jpg
>
>
> Ouch.  Not sure what to do here.
>
> Maybe we could cache something above find_pc_section ->
> update_section_map, to avoid the section look ups.
> From [2], we see that this is in the inline frame sniffer.
> Maybe we can add a shortcut here, based on assuming that if
> we're stopped at the jit event breakpoint address, then we're
> not stopped at an inlining site.  That is, a trick similar to
> the pc_at_non_inline_function check in infrun.c.
>
> So, as a quick hack, if you make inline_frame_sniffer bail out early
> with 0, does it improve things?

With

diff --git a/gdb/inline-frame.c b/gdb/inline-frame.c
index f8ba249..49cae00 100644
--- a/gdb/inline-frame.c
+++ b/gdb/inline-frame.c
@@ -206,6 +206,7 @@ inline_frame_sniffer (const struct frame_unwind *self,
                      struct frame_info *this_frame,
                      void **this_cache)
 {
+  return 0;
   CORE_ADDR this_pc;
   const struct block *frame_block, *cur_block;
   int depth;

The timing looks the same. =(

>
>>
>>>>>> It'd even be better to somehow restrict breakpoint re-setting
>>>>>> to the jit modules that were added/removed/changed, but
>>>>>> that's harder.
>>
>>
>> I've re-read the 2011 thread and I think I have a slightly better
>> understanding now. IIUC we need to check if the newly registered file
>> contains any pending breakpoints. Is the problem that this is done by
>> checking it over all the registered object files? Is it possible to
>> avoid O(n^2) scaling without only re-setting on the jit object file
>> currently being modified?
>
>
> Batch loading the object files comes to mind.  From reading
> the code, it seems like gdb only reads on object file per
> JIT_REGISTER event.  The descriptor->relevant_entry one.
> Is that correct?  Is there a reason the loader couldn't batch
> compile all functions, only call the JIT_REGISTER once, and
> then have GDB follow descriptor->relevant_entry->next_entry, etc.?

What do you mean by "loader"? since you mentioned call JIT_REGISTER I
assume you mean JIT compiler?

At least for the julia JIT, we already try to batch compile as much as
we can (this is also necessary to save memory for example, since most
functions are much smaller than a page) However, it is impossible to
know all the functions a program is going to call so there'll be
continues jitting going on. For normal program this shouldn't be that
bad since it should execute a small number of functions most of the
time and the jit don't need to work anymore after some initial warm
up. However, the test suite is a very case since it is written to call
all the functions with many different types which will force the
compiler to emit a lot of functions and run them.

>
> If we could batch load, then we could also defer breakpoint re-set
> until all is loaded, as well as inhibit section map updates,
> as done in svr4_handle_solib_event for normal DSO loading.
>
> Thanks,
> Pedro Alves
>