[llvm-dev] [RFC] Making .eh_frame more linker-friendly (original) (raw)
George Rimar via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 21 00:41:48 PST 2017
- Previous message: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
- Next message: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .ehframe sections. If it is not too slow, it may make >sense to generate split .ehframe sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .ehframe sections by >default.
I'll start investigating the implementation and try to update/reimplement and check that all.?
(Can probably take some time because want to investigate llvm/mc code a little as it is new for me).
Either way, my aim is to make lld handle only split .ehframe sections to do gc-sections or ICF. Supporting both non-split and split section doesn't simplify it at all and >therefore doesn't make sense. It'd rather increase the work we need to do.
Yes and that is my concern. I think we can't just drop supporting optimization of objects produced not by clang/llvm-mc. If we drop supporting split section case, we will lose it and need to be sure that is fine for users of LLD. That probably the question is if other compilers will want to do the something same or not. Anyways that is a bit forward question probably, let me do experiments with it for start to check the idea.
George.
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171121/454437e8/attachment.html>
- Previous message: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
- Next message: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]