From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14335 invoked by alias); 17 Dec 2014 20:34:26 -0000 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 Received: (qmail 14323 invoked by uid 89); 17 Dec 2014 20:34:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 17 Dec 2014 20:34:24 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBHKYGpp000891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Dec 2014 15:34:17 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBHKYDov009105; Wed, 17 Dec 2014 15:34:14 -0500 Message-ID: <5491E8C4.502@redhat.com> Date: Wed, 17 Dec 2014 20:34:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eli Zaretskii , Jan Kratochvil CC: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, ktietz@redhat.com Subject: Re: [patch] compile: Fix MinGW build [Re: [mingw rfc] Add mkdtemp to gdb/gnulib/] References: <87a92pvc0w.fsf@codesourcery.com> <20141215124358.GU5457@adacore.com> <20141215171225.GA19674@host2.jankratochvil.net> <20141215181449.GA5457@adacore.com> <20141215182057.GA22226@host2.jankratochvil.net> <20141215183554.GB5457@adacore.com> <20141215184014.GA22610@host2.jankratochvil.net> <83y4q8wxk7.fsf@gnu.org> <20141215222801.GA28138@host2.jankratochvil.net> <83vblcw9hw.fsf@gnu.org> <20141217191755.GE21574@host2.jankratochvil.net> <83r3vyul89.fsf@gnu.org> In-Reply-To: <83r3vyul89.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00500.txt.bz2 On 12/17/2014 07:31 PM, Eli Zaretskii wrote: >> Date: Wed, 17 Dec 2014 20:17:55 +0100 >> From: Jan Kratochvil >> Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org, >> ktietz@redhat.com >> >>>> linux-tdep.c: >>>> set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap); >>> >>> Why is mmap needed here? >> >> The project obviously needs something like: >> (gdb) call dlopen("just compile piece of code.so"); >> >> But as dlopen() is intrusive to the inferior Tom decided it is better to do >> much less intrusive >> (gdb) print mmap(...) >> >> instead and reimplement what inferior dlopen() does >> in gdb/compile/compile-object-load.c - which is being done. > > Why is dlopen "intrusive"? Pasting here what I said recently on a glibc thread, re. reasons for not using dlopen for this. Off the top of my head, I'm sure there are more: - The user might want to evaluate an expression while the program itself has just called dlopen and is now stopped inside it. This pesky dlopen recursion thing. It's best if GDB only calls async-signal safe functions behind the scenes, if possible. Of course if the injected expression involves calls to async-signal unsafe code that breaks the inferior, the user gets what she asked for. - The program might have not been linked with -ldl. - I suspect there may be issues with messing with symbol resolution and self library walks in the inferior too. Not sure if RTLD_LOCAL is enough. dlmopen might be a better fit, but hmm, that isn't very well supported in GDB/glibc. - A lower level mechanism has much better chances of working on more targets and runtimes-of-languages-other-than-C with minimal changes. > ISTM that using the Windows equivalent of dlopen is exactly the right thing here. That may well be, though I think that it's better if "info shared" doesn't show the modules injected into the inferior, which using LoadLibrary (Windows's dlopen) would give you. Note that set_gdbarch_infcall_mmap doesn't need to implement the whole feature set of mmap. We only need to be able to carve out a piece of memory. Should map trivially to VirtualAlloc. I expect that we'll end up using this same gdbarch hook to allocate memory in the inferior when we need to coerce variables to the inferior. We currently call "malloc" for that, which isn't ideal in the sense that the inferior can well be already inside malloc when we do that, leading do deadlock or corruption. Thanks, Pedro Alves