search for: sht_x86_64_unwind

...p#L392 as we are trying to do cast to InputSection, though .eh_frame is not regular InputSection but EhInputSection. Basing on all above I supposed it should be fine to not emit SHF_LINK_ORDER flags for start. I changed implementation so that it emits multiple .eh_frames and sets sh_link field for SHT_X86_64_UNWIND sections, but don't set the SHF_LINK_ORDER flag. In that way only x64 target is affected and SHT_X86_64_UNWIND sections are known to be .eh_frame so can be handled on linker side not by name, what is also nice for start it seems. (Uploaded current version as diff 2 here: https://reviews.llvm.or...

>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make >sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by >default. I'll start investigating the