From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116542 invoked by alias); 29 Jun 2017 13:24:58 -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 116521 invoked by uid 89); 29 Jun 2017 13:24:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=lunch, arrives, H*r:sk:static. X-HELO: mail-io0-f179.google.com Received: from mail-io0-f179.google.com (HELO mail-io0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 13:24:55 +0000 Received: by mail-io0-f179.google.com with SMTP id r36so6824804ioi.1 for ; Thu, 29 Jun 2017 06:24:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=j+q+PhbqJ11SWJrKgcrHukioj1cgIM8cxa90AS+6ox0=; b=R7tRlhf2PigZPeG3qP2PhGfDoJuKgS3oF/t9yEXMBBTtxwF/fRJqmo4e6yV2z6xPg7 LGRtiRgGB2MAVIXNuk1UDpFfSWbmlM+USpK80kIMjUUIDBKK131hRZqLyIyYF5PMAY3f vsrpuzO71382E+4nE6edUjrkutV5wkU30+C1NFvnNefUoZ5acORBC/URN5pMU0E8Q4on 9GcLN3aQOjbp3bz8FEP0mfI2kXmr00N09GW4hV8otxYdDJF7xOK19VmOxPvSdkbSiPNW qLf0iEt69F87/J2PPHhpiLKuzYbqx2O/fDfHVUCj/e0kvFK2aLICsrCBPPiVZD1y5Iat r+sA== X-Gm-Message-State: AKS2vOxQQYR8sIyVBiXUVaYd+/Bu8/O5bKiXxPvWiTsO2azyYiOr9xRG hyZmWXuyLE8jhBwY X-Received: by 10.107.168.221 with SMTP id e90mr17894058ioj.68.1498742693813; Thu, 29 Jun 2017 06:24:53 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id m97sm2697861ioi.32.2017.06.29.06.24.52 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 29 Jun 2017 06:24:53 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/25] Use VEC for target_desc.reg_defs References: <1497256916-4958-1-git-send-email-yao.qi@linaro.org> <1497256916-4958-12-git-send-email-yao.qi@linaro.org> <297988f7-dffe-d922-0fcc-7b8c867c6c53@redhat.com> <86zicrcavm.fsf@gmail.com> <456b5fdb-891e-0195-2068-fc21fe6a0974@redhat.com> Date: Thu, 29 Jun 2017 13:24:00 -0000 In-Reply-To: <456b5fdb-891e-0195-2068-fc21fe6a0974@redhat.com> (Pedro Alves's message of "Thu, 29 Jun 2017 12:31:47 +0100") Message-ID: <86mv8rc4f5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00791.txt.bz2 Pedro Alves writes: >>> [Note that the IPA avoids calling the inferior's malloc during >>> normal operation, to avoid deadlocking the inferior. >>> This is initialization code, so it's not covered by the exact >>> same level of concern, even though one of the original goals was >>> to also be able to inject the IPA into a running inferior (e.g., by >>> calling dlopen via gdb). That does work (or at least used to), >>> but it's a little unsafe because the IPA initialization code >>> already calls malloc and other non-async-signal-safe functions. >>=20 >> Such usage is documented, at least, >> https://sourceware.org/gdb/onlinedocs/gdb/Server.html > > Yeah. We also call "malloc" in the inferior (value_allocate_space_in_inf= erior) > for coercing arrays, etc. to the inferior ('print "hello"', etc.) which > suffers from the same problem. I'm often surprised how we > don't hear more bug reports about that. > I can understand IPA calls malloc may cause deadlock in the inferior, if the inferior has already acquired the lock for malloc. Think it a bit more during lunch, I don't understand how it is related to non-async-signal-safe functions? Is it that main program executed some non-async-signal-safe function, signal arrives, goes to signal handler, hits a breakpoint or fast tracepoint here. Then, the non-async-signal-safe functions may be executed again either by gdb inferior call or IPA. If this is the problem, ... >>=20 >>> I guess std::vector would make it possible to use a custom >>> allocator in the IPA that would allocate memory with mmap >>> directly (or we'd make the IPA's xmalloc allocate with mmap, >>> and then the allocator would use xmalloc).] >>=20 >> Do you suggest that we need to use std::vector plus a customized >> allocator which uses mmap? > > No, not now, at least. At first I thought that using VEC instead of > static arrays would be the introducing the problem of using > malloc in the initialization path. Then while writing a > review in that direction I looked at the code and > realized/remembered that it's not really a new problem. > But I chose to dump my thoughts on how that might > be fixable in the future as a parenthesis. I don't mean > to go fix that now. ... then, we can't use std::vector either, because it may throw exception, or we somehow need to guarantee that the std::vector we used doesn't throw exception. --=20 Yao (=E9=BD=90=E5=B0=A7)