This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [unladen-swallow] Re: [RFA] Add interface for registering JITed code


On Fri, Jul 31, 2009 at 8:01 AM, Thiago Jung
Bauermann<thiago.bauermann@gmail.com> wrote:
>
> Ok, I had one night's sleep over this, and just re-read the thread. :-)
>
> Em Quinta-feira 30 Julho 2009 15:01:17 Thiago Jung Bauermann escreveu:
>> Em Quinta-feira 30 Julho 2009 12:12:50 Tom Tromey escreveu:
>> > >>>>> "Reid" == Reid Kleckner <rnk@mit.edu> writes:
>> >
>> > Tom> Yeah. ?This would work if you had two JITs in a process, say loaded
>> > Tom> dynamically, and the various __jit symbols had hidden visibility.
>> >
>> > Reid> I think if someone has that use case, then they can write a client
>> > Reid> side library that wraps the __jit symbols and make the two JITs
>> > call Reid> that.
>> >
>> > Yeah, I changed my mind, let's not worry about it. ?If it ever comes up,
>> > we can deal with it then without breaking compatibility.
>>
>> If/when someone wants to add another scripting language to GDB, we will be
>> bitten by this issue. I can see that happening already. :-)
>
> I still think this will happen soon enough ...
>
>> You're saying that the current patch is extensible to deal with that?
>
> ... but I agree with Reid in that the inferior (or client) can deal with that
> case internally (also it seems fair, since it is the client who wanted to have
> two JITs in the first place. :-) ). It is nice that the GDB-facing interface is
> as simple as possible.
>
> Also the protocol is versioned. That is awesome. I don't have worries
> regarding this issue.

Great, I really didn't want to tackle that issue from the GDB side.  :)

>> Also, changing subjects: it is important that this feature works on core
>> files, or at least is forward-compatible with such a feature. I think this
>> needs to be thought through before the patch goes in.
>
> I still think that the patch needs to be tested with a core file scenario
> before it is checked in. Since said scenario is similar to attaching to a
> running process, it will likely magically work, though.

Well, it didn't magically work because the jit_inferior_create_hook
was getting called twice for core files instead of once.  What would
happen is that the binary would get loaded, the hook called, there
would be no debug info, the memory would get loaded, it would get
called again, and it would think that it already read the descriptor.
So I made it look for new code every time just in case, and now it
works.

Here's an updated patch.  What else needs to be dealt with?

Reid

Attachment: jit-patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]