This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [unladen-swallow] Re: [RFA] Add interface for registering JITed code
- From: Reid Kleckner <rnk at google dot com>
- To: uweigand at de dot ibm dot com
- Cc: tromey at redhat dot com, Reid Kleckner <rnk at mit dot edu>, gdb-patches at sourceware dot org, unladen-swallow at googlegroups dot com
- Date: Fri, 24 Jul 2009 16:55:12 -0700
- Subject: Re: [unladen-swallow] Re: [RFA] Add interface for registering JITed code
- References: <m3y6qf9tz7.fsf@fleche.redhat.com> <200907241130.n6OBUwMe004564@d12av02.megacenter.de.ibm.com>
On Fri, Jul 24, 2009 at 4:30 AM, Ulrich Weigand<uweigand@de.ibm.com> wrote:
>> Reid> + ? ? ?/* Hack to work around the fact that BFD does not take ownership of the
>> Reid> + ? ? ? ? memory for files allocated in memory. ?*/
>>
>> Is it possible to fix this directly in BFD? ?Since...
>>
>> Reid> + ? ? ? ?bim = (struct bfd_in_memory *) objfile->obfd->iostream;
>>
>> ... this is definitely fishy :-)
>
> I'd suggest that Reid instead use bfd_openr_iovec to access an ELF image
> directly in inferior memory, as is currently done e.g. by
> ?remote.c:remote_bfd_open
> ?spu-linux-nat.c:spu_bfd_open
> ?solib-spu.c:spu_bfd_open (is about to be introduced by the patch
> ?http://sourceware.org/ml/gdb-patches/2009-07/msg00546.html)
> This works without BFD changes or directly accessing BFD internals ...
I implemented this in the last patch I sent out. It was a lot of fun.
It turns out you need to call bfd_check_format before adding the
object file, or GDB segfaults. To make it even more awesome, the data
that needs to be initialized is hidden behind layers of struct unions
and macros and all kinds of indirection... But I agree that the iovec
is the right way to do it. The BFD_IN_MEMORY flag seems like a hack.
Should I leave that memory leak fix in? It's still an open bug for
GDB/BFD, but it's less critical now that it only happens when someone
does add-symbol-file-from-memory.
Reid