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

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

[tromey at sourceware dot org]

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

            Bug ID: 30026
           Summary: ctf test program gives weird results with "list"
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: tromey at sourceware dot org
  Target Milestone: ---

I tried the test programs in gdb.ctf.
If I debug one and then type "list" I get very weird output:

murgatroyd. ../gdb -nx ./outputs/gdb.ctf/cross-tu-cyclic/cross-tu-cyclic 
[...]
(gdb) list
1       ^?ELF^B^A^A


What's happening here is that in ctfread.c:scan_partial_symbols:

  if (strcmp (fname, ".ctf") == 0)
    {
      fname = bfd_get_filename (of->obfd.get ());
      isparent = true;
    }

  ctf_psymtab *pst = create_partial_symtab (fname, tup->arc, cfp,
                                            partial_symtabs, of);

IOW, ctfread is saying that the source file for this psymtab
is the executable itself, which is clearly wrong.

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick.alcock at oracle dot com

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

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

[nick.alcock at oracle dot com]

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.

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

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
It's fine if 'list' just picks some random source file.
What's at issue here is that using the executable as the
symtab's file is incorrect in gdb.

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

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

[nick.alcock at oracle dot com]

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

--- Comment #3 from Nick Alcock <nick.alcock at oracle dot com> ---
Is there any way to say "every source file", "global scope" or failing that
"the source file you're looking at right now"? Picking some random source file
that isn't even the one you're looking at feels hugely confusing and isn't even
right (since any given shared type might not be in scope in that source file at
all, though that's probably not a problem for debugger use, which is one reason
why CTF puts things at global scope so promiscuously.)

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

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

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Nick Alcock from comment #3)
> Is there any way to say "every source file", "global scope" or failing that
> "the source file you're looking at right now"? Picking some random source
> file that isn't even the one you're looking at feels hugely confusing and
> isn't even right (since any given shared type might not be in scope in that
> source file at all, though that's probably not a problem for debugger use,
> which is one reason why CTF puts things at global scope so promiscuously.)

There's not really directly a way to say that, but anyway you
definitely can't do it by setting the symtab file to something
other than a source file.

I don't really know anything about CTF or its model.
Are there situations where no source file is known at all?
I see from the tests that sometimes source files are known.

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

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

[nick.alcock at oracle dot com]

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

--- Comment #5 from Nick Alcock <nick.alcock at oracle dot com> ---
Getting back to some of these bugs... we don't exactly ever know source files,
as such. What we keep is enough info to be able to disambiguate types which
have the same name in multiple different translation units, but different
definitions. Using the translation unit name seems more likely to be useful to
the end user than, say, just using a number.

These are stored in dictionaries (.ctf archive members) which are children of
the one big parent dictionary in which all unambiguously-defined types are
stored, so that if a user wants to look at one particular conflicting type, all
the unambiguously-defined types are visible as well (and the conflicting types
can all refer to any unambiguously-defined type too).

(This nearly always works, but even now we have some situations in which we
have to fall back to just using a number to distinguish translation units,
horrible though that is, such as if you compile one source file repeatedly
with, say, different #defines, then link them all together. See commit
6bd2318f328.)

So, in brief... we won't always have a source file, but we will have archive
members for all source files for which conflicting types exist, and any others
can always use the parent .ctf dictionary and get all their types (and all
other unconflicting types too: getting extra types from other translation units
that would be valid in this one if they were in scope is rarely annoying to
debugger users, I find).

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

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

[tromey at sourceware dot org]

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

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Nick Alcock from comment #5)
> Getting back to some of these bugs... we don't exactly ever know source
> files, as such.

That's totally fine... I mean, I don't know exactly what form the fix
ought to take here.  This bug is just pointing out that what the code
currently does is wrong -- it tries to display the ELF to the user as
if it were the source.

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