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

[Joel Brobecker <brobecker at gnat dot com>]

> I made that suggestion because it sounded like the addition you made
> caused some percepted slow-down of the psymtab scan.  If that is not
> true, consider my reservations to be withdrawn.

My original message probably wasn't clear. My concern was not exactly
about performance, but rather code duplication.  Currently, the task
of scanning the symbols in the .debug_info data to build the psymtabs
is simplified by following the DW_AT_sibling attribute. This attribute
is not guaranteed to be always generated when convenient for the debugger,
but it helps when it is there.

In the .debug_line data, there are no such links. You really have
to read byte after byte to interpret the data, and the number of
bytes to read depends on the instruction. If you screw up at some
point, you will end up slightly off and will therefore necessarily
screw up the rest of the program (or you even fail to interpret it).

My prototype patch almost duplicates a piece of code that's not really
that complex, but the real problem is that it doesn't know how to
recover from an error. I was trying to describe this issue for which
I didn't see any simple solution, except doing some surgery in the
function we currently have that reads that data and stores it into
the full symtab.

Hmmm, maybe the best approach to mitigate my concerns would be
to actually make dwarf_decode_lines() a bit more general. Right
now, its purpose is limited to storing the data it read directly into
the appropriate symtabs. Modifying it to allow the us to build both
symtabs but also psymtabs would make it possible to share this code.

Hmmm, could I even keep it as it is?  The only parts that tie this
function to symtab building seem to only be from using start_subfile()
and record_line() from buildsym.c. So maybe we can reuse this function
directly as is: it would build subfiles, and then we could dig out the
necessary information from there to build the psymtabs?  I even believe
we could save these subfiles in the private part of the "main" psymtab
so we don't have to rescan these tables again during the psymtab to
symtab conversion?

Sounds like a good idea, doesn't it? Before I start experimenting, 
does anybody know buildsym.c enough to tell me if it would be ok to
use the functions above outside of the context of building symtabs,
and then to save the subfiles chain for later use during the psymtab
to symtab conversion?

Thanks,
-- 
Joel