[Bug symtab/30026] ctf test program gives weird results with "list"

["nick.alcock at oracle dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30026

--- Comment #1 from Nick Alcock <nick.alcock at oracle dot com> ---
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 linking
with --ctf-share-types=share-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 source
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 all:
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 described
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 need
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 move
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.