search for: fdes

...dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly Hi Evgeny, > 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, it still needs some details. Not all of them, but anyway, handling of .eh_frame sections is still a special case, even if we split all the content at compile time. > What do you mean “one place or two”? If I understand it right, the RFC is about helping a linker to eliminate u...

...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 or two? What do you mean “one place or two”? If .eh_frame_hdr is not created a linker does not need to parse .eh_frame sections. It simply merges them into one section. The format of .eh_frame allows to do this without...

I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. And emitting discontiguous functions is a fundamental goal of this, right? On Wed,

...size bloats with regards to eh_frame, the reasoning is similar. > Restricting the section creation to only basic blocks that have profiles will > reduce this a lot more. > > Importantly, if CFI support were available for discontiguous ranges we wouldn't > have to duplicate CFI FDEs and the bloats would be near minimal. > > BOLT parses CFI and DWARF and generates compact information by rewriting it. > Whereas, Propeller uses lld which uses relocations and sections to fixup but > does not rewrite it. This is by design and that lld is not DWARF and CFI > aware. W...

...that a > block can be put anywhere by the linker. That’s a significant bloat that is > not cleaned up later. So, during link time, if N blocks from the same > function are contiguous in the final layout, as it should happen most of > the time for any sane BB order, we would have several FDEs for a region > that only needs one. The bloat goes to the final binary (a lot more FDEs, > specifically, one FDE per basic block). > > BOLT will only split a function in two parts, and only if it has profile. > Most of the time, a function is not split. It also has an option not to &...

...ng is similar. > > > Restricting the section creation to only basic blocks that have profiles will > > > reduce this a lot more. > > > > > > Importantly, if CFI support were available for discontiguous ranges we wouldn't > > > have to duplicate CFI FDEs and the bloats would be near minimal. > > > > > > BOLT parses CFI and DWARF and generates compact information by rewriting it. > > > Whereas, Propeller uses lld which uses relocations and sections to fixup but > > > does not rewrite it. This is by design and tha...

...put anywhere by the linker. That’s a significant bloat that is >>> not cleaned up later. So, during link time, if N blocks from the same >>> function are contiguous in the final layout, as it should happen most of >>> the time for any sane BB order, we would have several FDEs for a region >>> that only needs one. The bloat goes to the final binary (a lot more FDEs, >>> specifically, one FDE per basic block). >>> >>> BOLT will only split a function in two parts, and only if it has >>> profile. Most of the time, a function is n...

...that a > block can be put anywhere by the linker. That’s a significant bloat that is > not cleaned up later. So, during link time, if N blocks from the same > function are contiguous in the final layout, as it should happen most of > the time for any sane BB order, we would have several FDEs for a region > that only needs one. The bloat goes to the final binary (a lot more FDEs, > specifically, one FDE per basic block). > > BOLT will only split a function in two parts, and only if it has profile. > Most of the time, a function is not split. It also has an option not to &...

On 02/12/10 12:53, Renato Golin wrote: > On 2 December 2010 11:26, Duncan Sands<baldrick at free.fr> wrote: >> It occurs when doing LTO and inlining functions written in one language >> into functions written in another, thus my Ada inlined into C++ example. >> Mixed language programming is quite common, so it may be worth supporting >> this, but it's not

...n doing network interfaces bonding with LACP 801.3ad with layer3+4 hashing policy, because the trafic to one remote host/service will improperly be balanced over bonded interfaces with Centos. Is there any known kernel patch or reason to explain this behavior ? thanks for any hints. best regards FdeS

Hello, Renato > Are you actively working in that area? No, I started to experiment with ARM EH ~year ago, but never had anything complete, unfortunately > My main concern is that DwarfException is not extensible at all. I can't inherit from it (DwarfWriter creates it directly) and there are no call backs to target-specific code (nor registration of such mechanism). Why do you need

> -----Original Message----- > From: Anton Korobeynikov [mailto:anton at korobeynikov.info] > > Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, > sjlj excheptions on arm/darwin). I have some patched uncommitted for > EH on ARM but they are too far from being complete. Hi Anton, Are you actively working in that area? I did some experiments and managed to

...you will just lose your time. 3) Try to generate EXACTLY what llvm is generating. So, I extracted the __eh_frame section from a simple C program. otool -s __TEXT __eh_frame hello.o I figure out from the hexadecimal dump where the CIE lies. Then, I generate exactly the same. Then, generate the FDEs for each function. Again, use the dump of the __eh_frame section as a guide but add your own virtual machine instructions. Of course do not copy blindly what llvm generates since some fields like length, etc mst be changed! Then the problem arises: You have to inform the running program that a...

...0x0 .byte 0xB2, 0x1 > Here are his comments: The problem is that the linker parses FDE which gives it all the LSDA starts. The __eh_frame and __gcc_except_tab sections should not need any labels, since the structure in them is self describing. But with this padding, the LSDA starts from the FDEs and the GCC_except_table* labels are now different. It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unno...

...that a > block can be put anywhere by the linker. That’s a significant bloat that is > not cleaned up later. So, during link time, if N blocks from the same > function are contiguous in the final layout, as it should happen most of > the time for any sane BB order, we would have several FDEs for a region > that only needs one. The bloat goes to the final binary (a lot more FDEs, > specifically, one FDE per basic block). > > BOLT will only split a function in two parts, and only if it has profile. > Most of the time, a function is not split. It also has an option not to &...

...t; + if (DebugFrame) >> + return DebugFrame.get(); >> + >> + // There's a "bug" in the DWARFv3 standard with respect to the target address >> + // size within debug frame sections. While DWARF is supposed to be independent >> + // of its container, FDEs have fields with size being "target address size", >> + // which isn't specified in DWARF in general. It's only specified for CUs, but >> + // .eh_frame can appear without a .debug_info section. Follow the example of >> + // other tools (libdwarf) and extract...

...nk LLD development direction vector currently is to avoid teaching linker about things it naturally should not be aware off. Like it should ideally work with sections as pieces and should not know about content. That is not always possible, for example we have to look inside .eh_frame to deuplicate FDEs, but that is probably what we would want to avoid in general. >It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units >as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to imple...

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

...e table is inside the function instead of in a new section, thus the size has to appear after the table), and add new things (.fnstart, .fnend, .personality, etc), and make sure all Actions are in conformance with GCC's intrinsics. Also, looks like gcc doesn't produce the CIE nor any of the FDEs, so maybe I have to suppress that as well. > > For all those changes, the only place I can implement, AFAIK, is DwarfException. Now, as a local hack, I have added a new ExceptionABI { None, ARM }; enum to MCAsmInfo to if/else inside DwarfException, but that's far from ideal. > >...

...that a > block can be put anywhere by the linker. That’s a significant bloat that is > not cleaned up later. So, during link time, if N blocks from the same > function are contiguous in the final layout, as it should happen most of > the time for any sane BB order, we would have several FDEs for a region > that only needs one. The bloat goes to the final binary (a lot more FDEs, > specifically, one FDE per basic block). > > BOLT will only split a function in two parts, and only if it has profile. > Most of the time, a function is not split. It also has an option not to &...