From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 56225385842B; Tue, 28 Mar 2023 23:01:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 56225385842B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680044516; bh=uLNGMf5U9NVf9USBDEO3Gs38MTJGennBNUjkcb6lcOo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SAls264lP0bx673PehYlMW523qfJOQDZT5GLM2Ue6FCc8xWCfiikkDHkoBqNKWBg4 v7kX+pWCwiw6lwFSW4ptFhatK0+/p5fU3VxYNDcEzFPXyUVeWZdY6a9aG/Goco2U// rj+gqIrla2VtQFzu5WdUOr00IBOas5hA0ZV2sElQ= From: "nix at esperi dot org.uk" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/109161] Bad CTF generated for stub in function scope Date: Tue, 28 Mar 2023 23:01:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: wrong-debug X-Bugzilla-Severity: normal X-Bugzilla-Who: nix at esperi dot org.uk X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109161 Nix changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nix at esperi dot org.uk --- Comment #2 from Nix --- It definitely shouldn't hang for invalid input, but that sort of proof agai= nst invalid input isn't even implemented for the deduplicator yet, let alone ev= ery other thing that recurses over the type graph. It's on the todo list... and it's not specific to objdump at all: ctf_dump (objdump/readelf), ctf_type_rvisit, ctf_type_compat, even foundational libctf stuff like ctf_type_resolve would hang if, say, we had a CTF_K_CONST node pointing to itself, even indirectly. This does mean that anything we use to detect cycl= es must be *cheap*. Now I was assuming I could only implement cycle-detection efficiently for t= he deduplicator (which would usually suffice, since linking is the first thing that is usually done to compiler-generated CTF) -- but it occurs to me now = that I could use a similar technique in ctf_type_rvisit, which will handle ctf_d= ump: I can probably do the same for the other recursive type-traversing function= s, and handle all of them with the same cycle-detection code, and then CTF manipulation on raw object files would be safe against cycles too. The algorithm in question (one of Hellman's more obscure) cannot guarantee immediate detection of cycles, but it will always detect them eventually, w= hich is good enough for this application. That's the price we pay for spotting cycles in constant space with almost no time overhead for the common, acycl= ic case.=