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

[Reid Kleckner <rnk@google.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