This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[debug-early] LTO streaming of on-the-side dwarf data structures


Gentlemen, your feedback would be greatly appreciated!

I was investigating why locals were not being early dumped, and realized Michael's patch was skipping decls_for_scope() unless DECL_STRUCT_FUNCTION->gimple_df was set. I assume this was to wait until location information was available. That design caused locals to be dumped LATE, which defeats the whole purpose of this exercise.

Since we want the local DECL DIEs to be generated early as well, we'd want the location information to be amended in the second dwarf pass. This got me thinking about deferred_locations, and all these on-the-side data structures that a second dwarf pass would depend on. Unless I'm misunderstanding something, we need a plan...

Basically, any early collected data that dwarf2out_finish() and dwarf2out_function_decl() need, would need to be LTO streamed out after early dwarf generation and streamed back before the second dwarf pass. For instance, I see at least the following that need to be streamed in/out:

	file_table
	deferred_locations
	limbo_die_list (and deferred_asm_name)
	decl_die_table
	pubname_table
	pubtype_table

We could either stream the hash tables and/or data structures above (and merge them from different compilation units upon stream-in), or we could come up with some way of annotating existing dwarf (to be read/merged back in and annotated). For instance, deferred_locations, decl_die_table, and limbo_die_lists need to associate a DIE with a TREE. We could tag the DIE with an artificial DW_AT_* that has some byte representation of the TREE and recreate the hash at LTO stream-in time. For other data structures (perhaps file_table and pub*_table), perhaps we could come up with yet another way of representing the data in Dwarf.

However...I don't know if this is worth the trouble, or if we should just stream the individual hash tables and data structures, and not bother with this dwarf gymnastics.

Did anybody have a plan for this? Am I misunderstanding something, or do we need to stream a lot of these on-the-side structures?

Aldy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]