Re: [RFC/dwarf-2] Add support for included files

[Joel Brobecker <brobecker at gnat dot com>]

On Fri, Jan 02, 2004 at 09:18:02AM -0500, Daniel Jacobowitz wrote:
> Well, the question is whether this works well enough.  Things _are_ in
> these files - DW_AT_decl_file points to them.  Do we need to also put
> things into the proper psymtabs?

At this point, I don't see anything else that we need.

> Otherwise the approach seems reasonable.

Thanks. I can submit a proper patch soon, but there is Eli's suggestion,
though:

Eli Zaretskii wrote:
> How about if we only do that scan when the file name is not found in
> the partial symbols, i.e. just before GDB is about to give up and
> report the file as nonexistent?  Assuming that the cases you have in
> mind are rare, this would mean faster operation in most cases.

I am a bit relunctant to go that way, because I think the current
approach of using a half-baked psymtabs to hold include files is
a bit too adhoc for my taste. Adding an extra step after having scanned
the psymtab list to iterate over all objfiles, and re-partially scan the
debugging information seems to be going one step further in
``legitimizing'' this adhoc approach. If I were to add this extra step,
I would rather introduce a separate data structure for include files,
and then we could build the list of include files on-the-fly as you
suggest when scanning this list.

Trouble is, we may have also made some assumptions in several
places of GDB's code that the psymtab list contains all source
files. I suspect that the extra step you are suggesting will not
affect most of the instances of the code scaning the psymtab list,
so only a few of them will in fact need to be updated. But I'd rather
fix the build_psymtab phase.

It seems a bit of effort for a gain that we haven't measured.
I would suggest going the simple way first and re-think it if
the performance becomes noticeably worse. If somebody has a large
app like mozilla that he can use to do some measurement, I would
sure appreciate how much slower it is to startup with the patch
I posted.

(Eli, I don't know about C++, but you have a good point about lex & yacc
code) 

Let me know what you all think.

Thanks,
-- 
Joel