From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SEa0OnsD12aGwh4AWB0awg (envelope-from ) for ; Tue, 03 Sep 2024 08:39:23 -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=EdNYqeQI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EB0C41E353; Tue, 3 Sep 2024 08:39:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-11.8 required=5.0 tests=ARC_SIGNED,ARC_VALID, BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS autolearn=unavailable autolearn_force=no version=4.0.0 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 EAF2A1E08F for ; Tue, 3 Sep 2024 08:39:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88B22385ED4A for ; Tue, 3 Sep 2024 12:39:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88B22385ED4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1725367162; bh=Caw371NiHwgfi7r5s844Jt3Qc1vl73ZPpUBwya/KStQ=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=EdNYqeQIL3SvTBm0Y+SKMfJO/BXjLiyi3rNnmVHCWoA24BbmQIr62HiTrb+QAh5F7 10B6UDIrxGH/PHrWJM7VO5YUchRdsA/PNVVXGrXZl3NYbaPsm2a8PpNAwapRKsT5NS Tm3OlhX1nPZEgC0BwlNyi9TPCJRKwsAelaWdppEo= Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) by sourceware.org (Postfix) with ESMTPS id 05C1B385DDCA for ; Tue, 3 Sep 2024 12:38:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 05C1B385DDCA ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 05C1B385DDCA ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725367125; cv=none; b=Swle2/LRZrjHVuZtWvP7QIJ3POImKpFctKN5NnD0cE3RSA9d80+g5wmhyJf205GPCg6awjm2GNOViUEKNlbqX2wum4tFtgiv5DCE2vc9seUYgp3t8tDTEyO6mGf/8FC7Thqlpw8a8vkLdi1eRzicEvTMk+r5R0WOGxvxKx2dMII= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1725367125; c=relaxed/simple; bh=Caw371NiHwgfi7r5s844Jt3Qc1vl73ZPpUBwya/KStQ=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=hGV1zvyxhtXIx64ZmU2sTm84n/z0XB7+FSBpmEAn0EhGoro9fIDVWMLyyyAVOOV9lovccuHpNJ457gl8o5Ywi8TwLexB0cRKOp1mj7ORuHNlM0iTI6HvT33CU7o55P/fVvDjkfozmIcp+u1O+gzpuctg5Z+Oldx2pMALc48V61w= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Tue, 03 Sep 2024 12:38:36 +0000 To: GDB mailing list Cc: Simon Marchi Subject: Re: Question re symbols, symtabs and blocks Message-ID: <9a101660b4b7b4abcddb49940f1fdf975fd7d1d4.camel@vrany.io> In-Reply-To: References: Feedback-ID: 40767693:user:proton X-Pm-Message-ID: 51018ce1261c95e283e50dc7dd05fa840e00751a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Jan Vrany via Gdb Reply-To: Jan Vrany Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Thu, 2024-08-29 at 10:41 -0400, Simon Marchi wrote: >=20 > On 2024-08-28 06:08, Jan Vrany via Gdb wrote: >=20 > > Hi, > >=20 > > 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? >=20 >=20 > 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.=C2=A0 It's just what would > make sense to me. Thanks, it makes sense. >=20 > > Also, must blocks of different symtabs be always disjunct > > (meaning, their start-end ranges must not overlap)? >=20 >=20 > What kind of symtab are you talking about? "struct symtab" or "struct > compunit_symtab"?=C2=A0 I don't think that blocks care about "struct symtab". Sorry. I meant compunit_symtab. > However, blocks are part of a blockvector, and each compunit_symtab has > its own blockvector.=C2=A0 So my intuition is that blocks belonging to > different compunit_symtabs should be disjoint, as compilation unit > address ranges are typically disjoints.=C2=A0=C2=A0 > But then I don't know if there > are weird cases,=C2=A0 Yeah, I have somewhat weird use case where I have an =20 executable that contains a static buffer which =20 is at runtime filled with with JIT-compiled code. =20 In order to debug that jitted code, I create =20 compunit_symtab, block, symtab, linetable and =20 all that and for example "b jitted_function" but=C2=A0 =20 "disass jitted_function" disassembles the whole =20 buffer. But looking at code more closely, it seems =20 "disass" uses different way to figure out what range =20 to disassemble. Anyways, I'll try to rework the code to add blocks for =20 jitted code to the existing compunit_symtab rather than =20 creating new one. Thanks! Jan > for instance I don't know how LTO affects this, if > compilation units start sharing some code. >=20 > Simon