search for: eh_frames

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

>Keeping .eh_frame separated should still simplifies the linker because >until the last step of building .eh_frame and .eh_frame_hdr, we don't >really need to parse .eh_frame sections. So, if we have separate .eh_frame >sections on -ffunction-sections, all we have to do is (1) garbage-collect >sections and (2) construct .eh_frame and .eh_frame_hdr sections from live

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

...ake this change to simplify only a small part of a linker? For huge C++ projects this could improve link time if GC is a bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have to have two versions of GC: one with parsing eh_frames and another without parsing. There can be input object files where .eh_frame is not split. -Evgeny From: Igor Kudrin <ikudrin at accesssoftek.com> Date: Friday, 10 November 2017 at 12:23 To: Evgeny Astigeevich <Evgeny.Astigeevich at arm.com> Cc: nd <nd at arm.com>, "llvm-de...

...there is information about unused symbols, the implementation is very simple. BTW there is no need to do full decoding of eh_frame records to remove garbage. Paul is right there will be code size overhead. Eh_frame is usually created per a compilation module with common information in CFI. Multiple eh_frames will cause a lot of redundant CFI. There might be a case when the total size of redundant CFIs will be greater than the total size of removed garbage. Thanks, Evgeny Astigeevich The Arm Compiler Optimization team From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of "Robins...

...there is information about unused symbols, the implementation is very simple. BTW there is no need to do full decoding of eh_frame records to remove garbage. Paul is right there will be code size overhead. Eh_frame is usually created per a compilation module with common information in CFI. Multiple eh_frames will cause a lot of redundant CFI. There might be a case when the total size of redundant CFIs will be greater than the total size of removed garbage. As I wrote in the previous message, I don't think there's a size issue in link results because even existing linkers merge CIEs by contents...

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from,

...ror/lld/blob/master/ELF/InputFiles.cpp#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 ve...

Please look at the fragment of the hex dump of LLVM-created ELF showing the beginning and end of .eh_frame: .eh_frame begin 000297a0 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..| 000297b0 1b 0c 07 08 90 01 00 00 18 00 00 00 1c 00 00 00 |................| <...skipped...> 0002cb00 00 00 00 00 0b 01 00 00 00 41 0e 10 86 02 43 0d |.........A....C.| 0002cb10 06 42

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory

>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

It seems that showing eh_frame section pieces in the map file is useful, but I wonder what would be a concrete use case of the feature. Do you mind if you ask you to describe your plan if you have a use case in mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file

Hi all, Our use case for LLVM requires us to parse the .eh_frame sections emitted by MCJIT (for callee-saved-register spill slots, amongst other things). Does it make sense to have an in-tree parser for .eh_frame, given that it will make such tasks a lot easier? -- Sanjoy

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish

Checking out LLVM from svn and building, I get: llvm[2]: Linking Release executable ModuleMaker (without symbols) /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_fr ame_hdr table will be created. /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); n o .eh_frame_hdr table will be created. /usr/bin/ld: error in

On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: > Hi, > > I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is

>> With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert: >> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o >> /usr/local/bin/ld: internal error in layout_eh_frame_section, at >> .././../gold/object.cc:1309 >> It is that place: >> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372 >> Did not investigate it,

On 12/18/2014 06:58 PM, Kevin Modzelewski wrote: > I'd be interested in that, though would it be an issue if it doesn't > have an in-tree user? Quite possibly. It would bit rot if nothing else. At minimum, we need a dumper tool - possibly an option to an existing one - which produces human readable output and a bunch of lit tests to ensure it's not broken by other changes.