From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zFBsFLCI0Gae8RgAWB0awg (envelope-from ) for ; Thu, 29 Aug 2024 10:41:52 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=rlUXBg8/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2FA801E0D1; Thu, 29 Aug 2024 10:41:52 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 131051E0AC for ; Thu, 29 Aug 2024 10:41:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 524D3385F027 for ; Thu, 29 Aug 2024 14:41:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 524D3385F027 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1724942509; bh=GDGL/WBaj0OLuoMXQjA677Ex/RxRScjNF8ARhyaqYEI=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=rlUXBg8/fw7qhjUHWAsJI+JMeEAOwq/M/BEHcsX/Y5gfhE7pevDmkFqvys1VTH/nO FVTPCU1wCCVWFW5HFHuVZzhN6oV7eR1NXmnTVLZuw+KzDyUzfg7JVEgwTVSWysfk0g baeSdlRkNyqfFysUV6iWySwPJHh7IsYRLWT9v6Eg= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id F0B153858402 for ; Thu, 29 Aug 2024 14:41:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F0B153858402 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F0B153858402 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724942472; cv=none; b=aA8mPNAuHKgzPg9Wo7QE7bszKJ3a2I/WHiH+P1Y6jQbc/FGrsVoKwIFWc9VhghF7XGVBQ/YeWn9AAsbC60rW6C3+0bWnNHoLyF92sjnHYuaU4lERcdo5HJZIoeOnp12Q98wzAT/f6/BhzP5EvY5SPG0Kq1M5opMzeBur6iUVRKA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724942472; c=relaxed/simple; bh=d1blahy/zL/3QMXb6gNxUIe8Bjs/3usfPfoK7mB1PHI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WKBFvJGV53a+R+g/h3BeehPNR5J9mOU+vCEmMl3AyObD3P5qmd4cB+3O52HZL5lMgGCQsMbBSkiIc1hlfFL8MGSSavYpamGs2SiR+FZ4RqfTp1b2PBOzAQihWpUy6usueu8jC3HrNPy2GFCMjzUy6wKu6SVLAT+pNKtGi8dLI8o= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B50A11E08C; Thu, 29 Aug 2024 10:41:07 -0400 (EDT) Message-ID: Date: Thu, 29 Aug 2024 10:41:07 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Question re symbols, symtabs and blocks To: Jan Vrany , GDB mailing list References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, 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@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 2024-08-28 06:08, Jan Vrany via Gdb wrote: > Hi, > > in GDB, are there any constraints for blocks belonging to > to particular symtab? Like: must each blocks' start and end address > be within its superblocks' start and end address? This is how my mental model works, that children blocks must be entirely within their parents (even considering that blocks may be non-contiguous), but I don't have proof of that. It's just what would make sense to me. > Also, must blocks of different symtabs be always disjunct > (meaning, their start-end ranges must not overlap)? What kind of symtab are you talking about? "struct symtab" or "struct compunit_symtab"? I don't think that blocks care about "struct symtab". However, blocks are part of a blockvector, and each compunit_symtab has its own blockvector. So my intuition is that blocks belonging to different compunit_symtabs should be disjoint, as compilation unit address ranges are typically disjoints. But then I don't know if there are weird cases, for instance I don't know how LTO affects this, if compilation units start sharing some code. Simon