From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 520C73858D3C; Mon, 23 Jan 2023 11:45:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 520C73858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674474309; bh=MMxooCrquyciOxA7RE3R84bKvpELLfjcy/H9Z1n8gcU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gaEMLDvxHenTFH7dF29mht5P0WyCTSc6PaM5N7HdcTBGZ/V6d/nSIIgWzY7tja/Pl 5KBTlo/a3mnkDiiiKiIjs4jMpWm7qVXcnhQlGv5CsYqPU9rCJU+3CoOMjK2VCBLnqw cIoLLQBhAhxLM4on6JSbGvewXVHOfL/t13WwwQRQ= From: "nick.alcock at oracle dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/30026] ctf test program gives weird results with "list" Date: Mon, 23 Jan 2023 11:45:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nick.alcock at oracle dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30026 --- Comment #1 from Nick Alcock --- Ewwww!! Definitely a bug, I'd say. But CTF is not terribly conventional here and might not be too much help. In general CTF does not provide source file information for types: as a space-saving measure, with the default linker options all types are visible= if they are in scope in any source file and do not have definitions that (transitively) conflict with any other. (To be more precise: types are all = kept in the shared dict when possible, and the only analogue of a "source file" binding CTF has is the name of the dict. Conflicting types -- or, when link= ing with --ctf-share-types=3Dshare-duplicated, types that appear in only one translation unit -- can be attributed to specific source files by looking at the name of the dict in which they were found. So we need to do *something* for the (overwhelmingly) common case of types found in .ctf. Whether we report them as found in whatever the current sour= ce file is for *all* source files, or whether we can signify "everything" or something, I don't know. (This is a significant improvement over the old days -- back in the Solaris era, CTF gave no indication of what source files things were found in at al= l: even conflicting types just picked one at random and threw the rest away, giving type graphs for things citing the other types that were best describ= ed as full of lies. We don't do *that* any more.) I'd be happy to find some way to track source file origins more closely in CTFv4, but it needs to be space-efficient and so far I haven't found an approach I feel is efficient enough. Doing it the obvious way requires N*M links (one per type per source file) and is obviously untenable: the links would use orders of magnitude more space than the types themselves. We'd ne= ed some way to group types by source-file scope, so that types found in commonly-used headers only got their origins stored once. v4 is likely to m= ove to a scheme where conflicting types, rather than being represented as parent/child CTF dicts, are encodeed in a single dict via labelled regions partitioning the dict, so they can refer to each other: it feels to me like this is the start of what we'd need to do to efficiently encode source file origins as well. --=20 You are receiving this mail because: You are on the CC list for the bug.=