From: Pedro Alves <palves@redhat.com>
To: Yichao Yu <yyc1992@gmail.com>
Cc: gdb@sourceware.org, Paul Pluzhnikov <ppluzhnikov@google.com>
Subject: Re: JIT debugging (Attach and speed)
Date: Tue, 22 Mar 2016 16:41:00 -0000 [thread overview]
Message-ID: <56F1759F.3070100@redhat.com> (raw)
In-Reply-To: <CAMvDr+TRSF16fKnnb9tWD4Xctek31Sdgx2m1ct=UctXL_b9vuA@mail.gmail.com>
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
next prev parent reply other threads:[~2016-03-22 16:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 14:56 Yichao Yu
2016-03-22 15:46 ` Pedro Alves
2016-03-22 16:10 ` Paul Pluzhnikov
2016-03-22 16:15 ` Pedro Alves
2016-03-22 16:23 ` Yichao Yu
2016-03-22 16:41 ` Pedro Alves [this message]
2016-03-22 16:47 ` Yichao Yu
2016-03-22 17:00 ` Pedro Alves
2016-03-23 2:18 ` Yichao Yu
2016-03-23 4:51 ` Yichao Yu
2016-03-23 18:24 ` Pedro Alves
2016-03-23 19:32 ` Yichao Yu
2016-03-23 19:48 ` Pedro Alves
2016-03-23 20:51 ` Yichao Yu
2016-03-24 1:17 ` Pedro Alves
2016-03-24 3:14 ` Yichao Yu
2016-03-24 21:02 ` Yichao Yu
2016-03-23 12:24 ` Pedro Alves
2016-03-23 13:31 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F1759F.3070100@redhat.com \
--to=palves@redhat.com \
--cc=gdb@sourceware.org \
--cc=ppluzhnikov@google.com \
--cc=yyc1992@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox