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

List:       gdb
Subject:    Re: JIT debugging (Attach and speed)
From:       Pedro Alves <palves () redhat ! com>
Date:       2016-03-22 16:41:03
Message-ID: 56F1759F.3070100 () redhat ! com
[Download RAW message or body]

On 03/22/2016 04:22 PM, Yichao Yu wrote:
> On Tue, Mar 22, 2016 at 12:15 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 03/22/2016 03:46 PM, Pedro Alves wrote:
> 
>> I re-read the 2011 discussion, and it seems like we had an idea for a fix:
> 
> IIUC the proposed fix might cause regression in some cases?

Yeah, there's no full fix available, only some ideas thrown out.
The last discussed one wouldn't cause a regression -- the
"longjmp"-caching idea.  We may still need to defer breakpoint re-set
to at most once per jit load event, something like Paul's original
patch, but with a breakpoint_re_set call somewhere.

It'd even be better to somehow restrict breakpoint re-setting
to the jit modules that were added/removed/changed, but
that's harder.

> 
>>>
>>> Do you know whether this happens with 7.11 and master, and if so,
>>> would it be possible for you to git bisect the culprit?
> 
> This is 7.11 package from ArchLinux. I could try bi-secting although
> apparently you are faster at pin-point the issue.
> 
>>
>> Currently, jit_inferior_created_hook -> jit_inferior_init is only
>> called when the inferior execs...
>>
>> Grepping around, I think that might have been
>> the fix for PR gdb/13431 (03bef283c2d3):
>>   https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html
>> which removed the inferior_created (jit_inferior_created_observer).
>>
>> Adding an inferior_created observer back likely fixes the issue.
> 
> I'm happy to test patches.

I'm happy to provide guidance, but a fix would likely happen faster
if someone else stepped up to write it.

Thanks,
Pedro Alves

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