search for: call_site

Hey folks, I'm trying to wrap my head around the implementation, purpose, and costs involved in both the GCC-extension v4 and standard v5 DW_TAG_call_site, call site parameters, addresses, etc. So picking up from some of the design discussion in https://reviews.llvm.org/D72489: Me (Blaikie): I'm not sure why AT_call_return_pc would be needed at a tail call site as the debugger must ignore it. As for emitting DW_AT_low_pc under gdb tuning, I thi...

Hi everyone, I run some functions using ORC JIT, now I need to add custom instrumentation. I want to add two callbacks to each function: ‘enterFunction' at the beginning and ‘leaveFunction' at the end. Intuition says that I could ‘just' insert CallInst's to the first and the last basic blocks in the function. Am I correct? Are there any other/better way to do this? Is there

...<martin.oriordan at intel.com> wrote: > > The '-finstrument-functions' option may already be sufficient for your needs. > > When selected this inserts the following two calls on entry-to and exit-from a function: > > __cyg_profile_func_enter(void* this_fn, void* call_site) > __cyg_profile_func_exit(void* this_fn, void* call_site) > > You can then provide a custom implementation of these calls to perform the analysis tasks that you require. > > The two parameters are the address of the function into which the instrumentation is inserted, and the add...

...the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of the ResolverState. (If it is necessary for call_site -> function, this should be necessary for call_site -> resolver... Event if I'm not sure to master all subtle reasons - code alignment/prologue ?) A mutex on the StubToResolverMap should prevent any possible race conditions. Every object (Emitter, Resolver, ResolverState) have now a priv...

...; Attached you will find a patch which follow your 1st option : a map > Stub_address -> JITResolver instance, except that the used map is a > "std::map" to apply the same upper_bound trick as in the map > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > call_site -> function, this should be necessary for call_site -> resolver... > Event if I'm not sure to master all subtle reasons - code alignment/prologue > ?) > A mutex on the StubToResolverMap should prevent any possible race > conditions. > > Every object (Emitter, Resolver, R...

...find a patch which follow your 1st option : a map > > Stub_address -> JITResolver instance, except that the used map is a > > "std::map" to apply the same upper_bound trick as in the map > > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > > call_site -> function, this should be necessary for call_site -> > resolver... > > Event if I'm not sure to master all subtle reasons - code > alignment/prologue > > ?) > > A mutex on the StubToResolverMap should prevent any possible race > > conditions. > > >...

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

...at up one of these days... Turns out I decided to do it now. Some of this relates to threaded-later-than-this-email replies I've read by the time I'm writing this email. Yep - for DIEs that don't need to be referenced (such as subprogram DIEs - assuming they aren't the target of a call_site - all global variable DIEs (don't think there's any way to target them in LLVM's current DWARF emission) using comdats and relying on the linker's guarantee (which is at least documented for some Unix linkers: "In the absence of the sh_link ordering information, sections from a...

...roup > (COMDAT or whatever) as the function's .text section; that way, if the > function is discarded, so is the .debug_info fragment. Offhand I can't > think of any cases (other than DW_AT_specification, addressed below) of > references to a subprogram DIE from elsewhere, The call_site DWARF would want to refer to a subprogram DIE, but that could be handled by (first pass) having a declaration subprogram in the initial fragment that the call_site could refer to using the usual assembler-resolved CU-relative offset. Of course that'd mean a bunch of (probably the bigger part) o...

It would help if you post the -O0 and -O1bitcode files. Does it reproduce with opt -O1? If so, use -debug-pass= to figure out when things started going wrong. Does it make sense to compare the bitcode against code generated for x86 target? Evan On Aug 16, 2009, at 11:46 AM, Jim Grosbach wrote: > All, > > The following relatively simple function is behaving oddly under SJLJ >

All, The following relatively simple function is behaving oddly under SJLJ exception handling. Specifically, it's being diagnosed by the optimizer as being a nounwind function, which is obviously incorrect. From what I can tell so far, something is going wrong analyzing the call to __cxa_end_catch() invoke arm_apcscc void @__cxa_end_catch() to label %Unwind unwind label

...ite information, new DINode metadata DICallSite and DICallSiteParam are defined and these are emitted by the Clang frontend. The metadata is associated to the call or invoke IR instruction. Here is an example: %call5 = call i32 @fed_em_strncmp(i8* %arraydecay, i8* %arraydecay1, i64 5), !dbg !114, !call_site !101 … !99 = !DICallSiteParam(argno: 1, variable: !91, expr: !DIExpression()) !100 = !DICallSiteParam(argno: 2, variable: !95, expr: !DIExpression()) !101 = !DICallSite(scope: !87, file: !3, parameters: !102, line: 40, calledSubprogram: !13) !102 = !{!99, !100, !103} !103 = !DICallSiteParam(argno:...

...San Jose, 2018. The feature is now fully implemented in internal Clang/LLVM 4.0 version. > We presented a talk on our work at FOSDEM 2019[4]. > Thank you for posting this. This looks very interesting! Since your proposal has a lot of different components, Sema support, DW_AT_call_site_parameter support, DW_OP_entry_value support, it will probably be best to split them out into separate reviews, but it's also good to discuss the proposal in its entirety first. I have a bunch of questions to make sure I fully understand what you are doing. Sure, we will post several patches,...

...gt; in internal Clang/LLVM 4.0 version. > > We presented a talk on our work at FOSDEM 2019[4]. > > > > Thank you for posting this. This looks very interesting! Since your > proposal has a lot of different components, Sema support, > DW_AT_call_site_parameter support, DW_OP_entry_value support, it will > probably be best to split them out into separate reviews, but it's also > good to discuss the proposal in its entirety first. I have a bunch of > questions to make sure I fully understand what you are doing. >...

On Wed, Jun 3, 2020 at 6:34 AM Robinson, Paul <paul.robinson at sony.com> wrote: > > DWARF was designed in an era when COMDAT and ICF were not a thing, or at least not common, certainly not when talking about function code. The overhead of a unit occurred only once per translation unit, so that expense was reasonably amortized. > > > > Splitting functions into their own