search for: dbc52e

>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

...f created .eh_frame section to point to corresponding .text.) With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when linking sample apps: ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o /usr/local/bin/ld: .eh_frame has both ordered [`.eh_frame' in /tmp/test-dbc52e.o] and unordered [`.eh_frame' in /usr/lib/gcc/x86_64-linux-gnu/5.4.1/../../../x86_64-linux-gnu/crt1.o] sections /usr/local/bin/ld: final link failed: Bad value Looks it's code explicitly restricts mixing sections with link order flag and without: https://github.com/gittu...