similar to: Getting _eh_frame parser for llvm

> On 20 January 2016 at 09:21, Igor Laevsky via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natural place for implementing such parser. >>

Hi Igor, Rafael I’m very sorry. You’ve both pinged me more than once about this and I haven’t yet been able to find the cause of the issue. Igor, the failures I saw on a number of bots were complaining about one of the CHECK lines in the test case (test/tools/llvm-objdump/eh_frame-arm64.test)I adapted in the given review. The line in question was: # CHECK: DW_CFA_def_cfa: reg31 +0 but the

Hi, I was very curious so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising. On 26 January 2016 at 09:19, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Sent from my iPhone On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

Sent from my iPhone > On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There is some eh_frame section parsing going on in the linker which is > required for .eh_frame_hdr creation and probably useful for dead-frame > elimination in the future. I think there's 2 linker parsers (a macho one and elf/coff), runtime dyld, and dwarf

> 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:

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

Hi Igor, On Oct 17, 2016, at 10:39 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: Hi Michael, Hi Igor, Hi Michael, Hi Michael, What I was referring to is that we can write something like this inside LPPassManager iteration: if

> On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com> wrote: >> >> Hi Michael, > Hi Igor, Hi Michael, > >> >> +CC llvm-dev >> >> My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to

Hi Michael, +CC llvm-dev My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to miss adding verifiers in some of the LPPassManager’s. One similar idea is to introduce LCSSAVerifier function pass and make LCSSA pass to be dependant on it. That will allow

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

Hi, Currently in AliasAnalysis we can model ModRef behaviour for functions which only access memory through their pointer arguments. However we can't express this propery as a function attribute. For example, for intrinsics we can specify ReadWriteArgMem or ReadArgMem attributes in tablegen definitions. But due to the lack of the related function attributes on the llvm ir level, this

Hi, LLVM's memory intrinsics are quite useful for performing various optimizations with frequently used memory operations. Unfortunately this intrinsics are not applicable for languages with guaranteed atomicity for their memory accesses (like Java for example). In order to overcome this limitation I'm thinking about adding set of intrinsics which will execute as a series of unordered

It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown. As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll

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

>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

Hi Andrew, > 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. >

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

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.

> I dont have a concrete design right now and I am happy to take any other ideas Three ideas come to mind, none of which are perfect: 1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer intrinsic instead of an extractvalue, and the selector should likewise be extracted with