From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by sourceware.org (Postfix) with ESMTPS id D74D0396E02D for ; Thu, 2 Jun 2022 14:12:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D74D0396E02D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f53.google.com with SMTP id k16so6642553wrg.7 for ; Thu, 02 Jun 2022 07:12:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=x+Vu8noHF7iJFkHwLbVrS+JbhpNcQnaN/+nz1Fh/IIo=; b=72kN4jEVBs3wDuojBLSTZeiSMyYeyS+HTKb59UsYWWnf1hP5g3A2UiIQVSmyRzxHyb RgKA/XJIHPX6Cuf1ejO7F+LFu9eX9DdqBxIiQAY5/c6cnjV/ABV1qF5ft2s2Tfiw4nV0 II25+vov/n7GHtvMSsYa7NRkSXEKiTPghoOQ76OQ3FvOJnO/eeFr5/Pbrbgh4TYc4rX4 LpcJpQ4Ui/wZrV6h7BEa8kQZJHsnuyzgqKXGy9+OcOyQxOp5yfgQByQ5o/5l2lsaMEL6 ZEYC28SDt2YIuSr8ODCFDa8LwClilGPrpFUkffPkXVSL/Cs2bwETwisWNGS7ec4rI9/V Fduw== X-Gm-Message-State: AOAM530pO41TUKEI5LogXnO/clFLT94rBv/2MKAjQBVU/iGdrabyYer5 8eEkYzzecKzRdDCDGq5+NrQ= X-Google-Smtp-Source: ABdhPJylGRQZB7Pl7uhBKYxJTHWuE/fId8kgFVgb7UjtmCuCPon/9ovz2dHCQ3u5xXdXCTLIz40XLQ== X-Received: by 2002:adf:cc87:0:b0:210:307b:2ec5 with SMTP id p7-20020adfcc87000000b00210307b2ec5mr3857579wrj.98.1654179156963; Thu, 02 Jun 2022 07:12:36 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id f22-20020a1c6a16000000b003942a244eebsm4889979wmc.48.2022.06.02.07.12.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jun 2022 07:12:35 -0700 (PDT) Message-ID: <9e99b32f-10c8-5dff-bb4f-575bfec8ded8@palves.net> Date: Thu, 2 Jun 2022 15:12:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 2/5] gdbsupport: Introduce interval_tree Content-Language: en-US To: Ilya Leoshkevich , Tom Tromey , Andrew Burgess Cc: Andreas Arnez , gdb-patches@sourceware.org References: <20220602133546.2948282-1-iii@linux.ibm.com> <20220602133546.2948282-3-iii@linux.ibm.com> From: Pedro Alves In-Reply-To: <20220602133546.2948282-3-iii@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 14:12:39 -0000 On 2022-06-02 14:35, Ilya Leoshkevich wrote: > > Adding N JITed sections has the complexity O((N**2)*log(N)), because > adding each section involves breakpoint handling, which needs to > resolve PCs and thus calls update_section_map(). When N is around 10k, > this renders GDB unusable. Does this adding of N JITed sections happen in batch? Like, is this from jit_inferior_init, where we loop over JIT objects? Or is it so that we get notified about JIT objects, one at a time? In places where we add symbols in batch, we defer breakpoint re_setting exactly to avoid problems like this, via SYMFILE_DEFER_BP_RESET or something similar. Looks like jit.c doesn't try to do that. Or is it not possible in the scenario in question? Like, doesn't the JIT API let you register more than one object file at once?