From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id B78A03858D33 for ; Fri, 6 Jan 2023 20:21:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B78A03858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 456CC1E110; Fri, 6 Jan 2023 15:21:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1673036466; bh=nXREdidAtPGRprf92Ih8dku3keV/PWAe9SPo9ZamVWM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=mKKTJBi0zHxj/2Qa49vkfzbTbN+mzMxVsV8Z+cuuiCJfqt96zwUkNAcfxujd4eA3E RTWRYOTFpoda1vP8+Sh+DHS7NZ29WVfORVnmN3ee9oSohonHTYyZ3tLm4BNLHUvS69 tvncKz7CYRMtxqSnGFdFCiIhpaEWuyuFXm52AbuI= Message-ID: <735caf65-fff8-bca0-2f55-6c2e8781eeb6@simark.ca> Date: Fri, 6 Jan 2023 15:21:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 1/1] Add support for symbol addition to the Python API Content-Language: fr To: dark.ryu.550@gmail.com, gdb-patches@sourceware.org References: <5c5901d9216f$700a9b10$501fd130$@gmail.com> From: Simon Marchi In-Reply-To: <5c5901d9216f$700a9b10$501fd130$@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Same as with the other patches, I can't apply that patch, it seems misformatted. On 1/5/23 20:37, dark.ryu.550--- via Gdb-patches wrote: > This patch adds support for symbol creation and registration. It currently > supports adding type symbols (VAR_DOMAIN/LOC_TYPEDEF), static symbols > (VAR_DOMAIN/LOC_STATIC) and goto target labels (LABEL_DOMAIN/LOC_LABEL). It > adds the `add_type_symbol`, `add_static_symbol` and `add_label_symbol` > functions > to the `gdb.Objfile` type, allowing for the addition of the aforementioned > types of > symbols. > > This is done through building a new `compunit_symtab`s for each symbol that > is > to be added, owned by a given objfile and whose lifetimes is bound to it. i > might be missing something here, but there doesn't seem to be an intended > way > to add new symbols to a compunit_symtab after it's been finished. if there > is, > then the efficiency of this method could very much be improved. It could > also be > made more efficient by having a way to add whole batches of symbols at once, > > which would then all get added to the same `compunit_symtab`. Indeed, I don't think there's a way today to add symbols to a finished compunit_symtab. Maybe it would be worth exploring that. First, to avoid creating one compunit_symtab per created user symbol. But also because I wonder how user-created symbols interact with existing symbols. Let's say I have a symbol that comes from DWARF in an existing compunit_symtab, and I create a user symbol for that function's address. The new symbol is in a new compunit_symtab. This means there is some overlap in the addresses of two compunit_symtabs. What would functions like find_compunit_symtab_by_address return? Should the new symbol be added to an existing compunit_symtab, if the address falls into an existing compunit_symtab's address range? I think I'll have more questions / worries, but I'll wait until I can actually apply the patch and read it (I can't read diffs, sorry). Simon