Re: [PATCH,V3 3/3] CTF: multi-CU and archive support

[Tom Tromey <tom@tromey.com>]

>>>>> Weimin Pan via Gdb-patches <gdb-patches@sourceware.org> writes:

> Now gdb is capable of debugging executable, which consists of multiple 
> compilation units, with CTF. An executable could potentially have one
> or more archives, which, in CTF context, contain conflicting types.   

Thank you for the patch.  I can't really comment on most of it, since I
don't know much about CTF and I've never managed to even run one of the
CTF tests.  However, I did have a question.

> +      dp = (ctf_psymtab *)pst->dependencies[i];

gdb style is a space after the cast.

> +  if (isparent)
> +    pcu->parent_psymtab = pst;
> +  else
> +    pcu->imported_symtabs.push_back (pst);

The imported symtabs logic for partial symbol tables is to support a way
to "paste together" certain symtabs.

The idea in gdb is that when searching a psymtab for a symbol, all its
included psymtabs are also searched -- the tree of inclusions form a
kind of "virtual psymtab".

This is either used to represent header files (if user==nullptr) or the
DWARF "partial unit" feature (if user!=nullptr).

In the bit of your introduction quoted above, though, it sounds like
this is probably not what you intend?  At least, I don't see how to
reconcile this with the "conflicting types" text.

Also I notice that the dependency tree isn't really represented in the
resulting symtabs, or at least it didn't seem that way to me.  I don't
know if this is invalid or not (there's probably no real rule), but it
at least seems a bit questionable.

If a CTF archive represents multiple compilation units, the more
ordinary thing to do would be to create one psymtab per each unit, and
just let them be separate.

I wonder if psymtabs are even needed or useful for CTF.  Depending on
how libctf works it might be preferable to get rid of them entirely and
just write a new implementation of quick_symbol_functions.

Anyway, if you did intend things to work this way, then it's fine by me.

thanks,
Tom