[PATCH] Better .debug_aranges fix (PR debug/48253)

Jason Merrill jason@redhat.com
Thu Mar 24 17:08:00 GMT 2011


On 03/23/2011 09:08 PM, Jakub Jelinek wrote:
>   const char *dw_fde_begin;
>   const char *dw_fde_end;
>   const char *dw_fde_hot_section_label;
>   const char *dw_fde_hot_section_end_label;
>   const char *dw_fde_unlikely_section_label;
>   const char *dw_fde_unlikely_section_end_label;
>   dw_cfi_ref dw_fde_switch_cfi; /* Last CFI before switching sections.  */
>   /* True iff dw_fde_begin label is in text_section or cold_text_section.  */
>   unsigned in_std_section : 1;
>   /* True iff dw_fde_unlikely_section_label is in text_section or
>      cold_text_section.  */
>   unsigned cold_in_std_section : 1;
>   /* True iff switched sections.  */
>   unsigned dw_fde_switched_sections : 1;
>   /* True iff switching from cold to hot section.  */
>   unsigned dw_fde_switched_cold_to_hot : 1;

Looking at this patch, without having previously paid much attention to 
the hot/cold partitioning code, I find these flags very confusing; it 
took me a while to figure out what they really mean.

It seems that we are sometimes splitting functions into hot and cold, 
and those partitions can either be in standard sections or 
function-specific ones.  So it seems like the information we want is:

Primary start/end label (dw_fde_begin/end)
Primary in standard section (in_std_section or cold_in_std_section)
Secondary section used (dw_fde_switched_sections)
Secondary start/end label (dw_fde_{hot,unlikely}_section_{,end_}label)
Secondary in standard section (in_std_section or cold_in_std_section)

It seems to me that we don't need to have the labels for both hot and 
cold sections in addition to begin/end, and we could replace 
dw_fde_switched_sections with just checking whether the secondary labels 
are NULL.

I think we could drop dw_fde_switched_cold_to_hot in favor of the 
primary/secondary model; for debugging purposes it doesn't matter 
whether the primary section is hot or cold.

This ought to cut down on the number of cases we have to handle in all 
the different places in dwarf2out that deal with this stuff.

Does that make sense to you?

Jason



More information about the Gcc-patches mailing list