From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24422 invoked by alias); 24 Jul 2009 23:55:27 -0000 Received: (qmail 24414 invoked by uid 22791); 24 Jul 2009 23:55:26 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Jul 2009 23:55:19 +0000 Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id n6ONtF1P010817 for ; Sat, 25 Jul 2009 00:55:16 +0100 Received: from wf-out-1314.google.com (wfd27.prod.google.com [10.142.4.27]) by wpaz29.hot.corp.google.com with ESMTP id n6ONtCOv012718 for ; Fri, 24 Jul 2009 16:55:13 -0700 Received: by wf-out-1314.google.com with SMTP id 27so551915wfd.1 for ; Fri, 24 Jul 2009 16:55:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr733189wfe.213.1248479712709; Fri, 24 Jul 2009 16:55:12 -0700 (PDT) In-Reply-To: <200907241130.n6OBUwMe004564@d12av02.megacenter.de.ibm.com> References: <200907241130.n6OBUwMe004564@d12av02.megacenter.de.ibm.com> Date: Sat, 25 Jul 2009 00:40:00 -0000 Message-ID: <25eb677d0907241655q11ca995dgd549b6a156f4de3c@mail.gmail.com> Subject: Re: [unladen-swallow] Re: [RFA] Add interface for registering JITed code From: Reid Kleckner To: uweigand@de.ibm.com Cc: tromey@redhat.com, Reid Kleckner , gdb-patches@sourceware.org, unladen-swallow@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00615.txt.bz2 On Fri, Jul 24, 2009 at 4:30 AM, Ulrich Weigand wrote: >> Reid> + =A0 =A0 =A0/* Hack to work around the fact that BFD does not tak= e ownership of the >> Reid> + =A0 =A0 =A0 =A0 memory for files allocated in memory. =A0*/ >> >> Is it possible to fix this directly in BFD? =A0Since... >> >> Reid> + =A0 =A0 =A0 =A0bim =3D (struct bfd_in_memory *) objfile->obfd->i= ostream; >> >> ... 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 > =A0remote.c:remote_bfd_open > =A0spu-linux-nat.c:spu_bfd_open > =A0solib-spu.c:spu_bfd_open (is about to be introduced by the patch > =A0http://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