search for: gcc_exception_table

No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers all function sections, which seems odd to me. On Thu, Oct 26, 2017 at 9:47 AM, Reid Kleckner <rnk at google.com> wrote: > Have you seen the discussion of SHF_LINK_ORDER on the generic-abi@ > mailing li...

...dly No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers all function sections, which seems odd to me. On Thu, Oct 26, 2017 at 9:47 AM, Reid Kleckner <rnk at google.com<mailto:rnk at google.com>> wrote: Have you seen the discussion of SHF_LINK_ORDER on the ge...

Hi, Many linkers including lld have a feature to eliminate unused sections from output to make output smaller (which is essentially a mark-sweep gc where sections are vertices and relocations are edges). lld and GNU gold have yet another feature, ICF, to merge functions by contents to save more space. When we remove or merge a function, we want to eliminate its exception handling information as