similar to: [LLVMdev] So what's the deal with debug_frame V eh_frame

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

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

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

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

Hi, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused

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

Folks, We're having some discussions about the behaviour of exception handling and Dwarf sharing unwind logic, tables, etc. and it seems that the code around it wasn't designed with any particular goal in mind, but evolved (like the EHABI) and now we're seeing the results from it. The problems below are assuming C vs. C++, but it actually apply to any possibly-exceptional vs.

Hello, Building an object file with ToT Clang: > Debug+Asserts/bin/clang -o penalty2.o -c penalty.cpp -g These are the debug-related sections produced: $ readelf -S penalty2.o |grep debug [ 5] .debug_info PROGBITS 0000000000000000 00000bd0 [ 6] .rela.debug_info RELA 0000000000000000 00002f80 [ 7] .debug_abbrev PROGBITS 0000000000000000

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

>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

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

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

Hi Igor, > It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right? Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to. > So, is there any difference whether it knows that in one place

> From: Renato Golin [mailto:renato.golin at linaro.org] > > We're having some discussions about the behaviour of exception handling and Dwarf > sharing unwind logic, tables, etc. and it seems that the code around it wasn't > designed with any particular goal in mind, but evolved (like the EHABI) and now > we're seeing the results from it. > > The problems below

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

> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way, > does it make sense to make 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:

I performed tests basing on first diff of https://reviews.llvm.org/D40352. (Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of 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

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

>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

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,