From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113083 invoked by alias); 28 Jun 2017 19:01:27 -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 112317 invoked by uid 89); 28 Jun 2017 19:01:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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 ESMTP; Wed, 28 Jun 2017 19:01:24 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A53353D97C; Wed, 28 Jun 2017 19:01:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A53353D97C Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A53353D97C Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A8BE4F6B4; Wed, 28 Jun 2017 19:01:22 +0000 (UTC) Subject: Re: [PATCH 11/25] Use VEC for target_desc.reg_defs To: Yao Qi , gdb-patches@sourceware.org References: <1497256916-4958-1-git-send-email-yao.qi@linaro.org> <1497256916-4958-12-git-send-email-yao.qi@linaro.org> From: Pedro Alves Message-ID: <297988f7-dffe-d922-0fcc-7b8c867c6c53@redhat.com> Date: Wed, 28 Jun 2017 19:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1497256916-4958-12-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg00772.txt.bz2 On 06/12/2017 09:41 AM, Yao Qi wrote: > Nowadays, target_desc.reg_defs is a pointer points to a pre-generated > array, which is not flexible. This patch changes it from an array > to a VEC so that GDBserver can create target descriptions dynamically > later. Instead of using pre-generated array, the -generated.c calls > VEC_safe_push to add each register to vector. > > Since target_desc.reg_defs is used in IPA, we need to build common/vec.c > for IPA too. Can you say more about the choice of VEC? It feels like new uses should come with a rationale for why it'd be preferred over std::vector. I'm guessing that it's because the gdb side uses VEC too? Or is it something else? (I can guess other reasons, but the point is that we shouldn't have to guess.) [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. 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).] Thanks, Pedro Alves