similar to: [LLVMdev] Windows x64 unwind info

Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() iterator to walk the object's symbols looking for functions and only functions marked with ExternalLinkage seem to show up. I'm not sure how I would access the Dwarf info from within there, is there a way? Thanks, Andrew On Wed, Nov 13, 2013 at 8:23 PM, Kaylor, Andrew

We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some

Yeah, take a look at the IntelJITEventListener code (in lib/ExecutionEngine/IntelJITEvents). It uses the debug info to find function names. -Andy From: Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code Hi Andy, In the NotifyObjectEmitted

Hi Rafael, comment explanation added now. Thanks. On Tue, Jan 14, 2014 at 8:31 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > LGTM with a comment explaining the issue. > > On 20 December 2013 03:50, Andrew MacPherson <andrew.macp at gmail.com> > wrote: > > Thanks Joerg. > > > > I've made the change you suggested and verified that it

Thanks Joerg. I've made the change you suggested and verified that it still works. I think the noinline is still required though as this function can be called from a couple of places and gdb will want to set its breakpoint on the single function address. Let me know if you think otherwise though. Cheers, Andrew On Fri, Dec 20, 2013 at 11:52 AM, Joerg Sonnenberger < joerg at

>From NotifyObjectEmitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc:

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows

Hello everyone, i’m using LLVM (updated to 3.1 after seeing that bug, but it’s the same with 3.0) for running a bitcode on a C++ program, and Clang for compiling it. My code work perfectly, as expected on x64, but crash on x86. I’m on Windows 7 x64 and LLVM + Clang was compiled using Visual Studio 2010 (tested in both Release and Debug build). Project was make using CMake. Here is my code:

Hi all, Looking into ClamAV, it seems that the output is highly asynchronous, so a simple diff is obviously bogus. Since the output is mainly a report of what's happening, without any logical sequence, I can sort both outputs and diff them, for a similar (though not perfect) result. If you sort clamscan.out-nat and clamscan.out-simple, you'll see that they're identical. I'm not

YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not

I intend to use this to support oprofile's ability to symbolize JITted code through the interface described at http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I believe the interface will also be useful for gdb support. I'm considering adding some flags to the JITEventListener to let the JIT avoid collecting information no listener is going to use, but I won't do that

On 2 April 2013 21:20, Török Edwin <edwin+ml-debian at etorok.net> wrote: > You can pass all the filenames from the inputs/ directory directly on the > command-line, instead of specifying -r inputs/. > That way the order of scanning will be exactly the one specified on the > command-line. > Hum, I think I can fix that with Make... --renato -------------- next part

Ack, sorry. I should have sent this to llvm-commits instead. :-P Followups there please. On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey Yasskin<jyasskin at google.com> wrote: > I intend to use this to support oprofile's ability to symbolize JITted > code through the interface described at > http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I > believe the interface

Hi Jeffrey, This looks very good. Thanks. Some comments: +/// JitSymbolEntry - Each function that is JIT compiled results in one of these +/// being added to an array of symbols. This indicates the name of the function +/// as well as the address range it occupies. This allows the client to map +/// from a PC value to the name of the function. +struct JitSymbolEntry { A nitpick. Please

On Wed, Jun 24, 2009 at 2:43 PM, Evan Cheng<evan.cheng at apple.com> wrote: > Hi Jeffrey, > > This looks very good. Thanks. Some comments: > > +/// JitSymbolEntry - Each function that is JIT compiled results in > one of these > +/// being added to an array of symbols.  This indicates the name of > the function > +/// as well as the address range it occupies.  This

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *write ELF image

Hi Andrew, this sounded a plausible explanation, because the X86 processor does not have an instruction to calculate the power function. So I tried the llvm.sin.f32 intrinsic, as the X86 processor family does have an instruction for that, but I still get the same problem. While you may still be right, there is at least something else going on as well. Thanks for your input, though. Taco.

Hi, On 2017-02-01 23:20:40 -0800, Andres Freund wrote: > > Can you give a pointer to the patch so that I can assess the rough > > complexity? If it's simple enough, I'd be happy to help get it > > reviewed and in. If it's more complicated, I probably won't have the > > time to assist. > > Patch (and a prerequisite) attached. Took me a while to get

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed