search for: notifyfreeingobject

...std::function defaulting to empty? Is that just for historical raisins, or is there a deeper reason? To be able to use existing JITEventListeners - it'd surely be a shame to have to rewrite them anew - in custom stacks it also appears that there's no easy way to call JITEventListener->NotifyFreeingObject() - the to-be-freed objects aren't readily available in RTDyldObjectLinkingLayer. Greetings, Andres Freund

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging support MCJIT has is provided by the RuntimeDyld utility, > > which ORC shares. I would expect anything in that document to apply to &...

...(K) already exists in the map All of this leads me to believe there is some sort of race. Theory: with two unit tests A and B running back to back... 1. Unit test A allocates and deallocates a `MemMgr` (or whatever other object we are using for a key) at address X 2. Unit test A calls ` notifyFreeingObject` to free the object at K=X but gets stuck (does not lock) the ` JITDebugLock` mutex here<https://github.com/llvm/llvm-project/blob/3d5360a4398bfa6878f94ca9ac55bc568692c765/llvm/lib/ExecutionEngine/GDBRegistrationListener.cpp#L181> for whatever reason 3. Meanwhile unit test B allocates a `M...

...ve there is some sort of race. Theory: >> with two unit tests A and B running back to back… >> >> >> >> 1. Unit test A allocates and deallocates a `MemMgr` (or whatever >> other object we are using for a key) at address X >> 2. Unit test A calls ` notifyFreeingObject` to free the object at K=X >> but gets stuck (does not lock) the ` JITDebugLock` mutex here >> <https://github.com/llvm/llvm-project/blob/3d5360a4398bfa6878f94ca9ac55bc568692c765/llvm/lib/ExecutionEngine/GDBRegistrationListener.cpp#L181> >> for whatever reason >&...

...ey (K) already exists in the map All of this leads me to believe there is some sort of race. Theory: with two unit tests A and B running back to back… 1. Unit test A allocates and deallocates a `MemMgr` (or whatever other object we are using for a key) at address X 2. Unit test A calls ` notifyFreeingObject` to free the object at K=X but gets stuck (does not lock) the ` JITDebugLock` mutex here<https://github.com/llvm/llvm-project/blob/3d5360a4398bfa6878f94ca9ac55bc568692c765/llvm/lib/ExecutionEngine/GDBRegistrationListener.cpp#L181> for whatever reason 3. Meanwhile unit test B allocates a `M...

...; + PerfJITEventListener(); > + ~PerfJITEventListener() { > + if (MarkerAddr) > + CloseMarker(); > + } > + > + void NotifyObjectEmitted(const ObjectFile &Obj, > + const RuntimeDyld::LoadedObjectInfo &L) override; > + > + void NotifyFreeingObject(const ObjectFile &Obj) override; > + > +private: > + > + bool InitDebuggingDir(); > + bool OpenMarker(); > + void CloseMarker(); > + bool FillMachine(LLVMPerfJitHeader &hdr); > + > + void NotifyCode(Expected<llvm::StringRef> &Symbol, uint64_t CodeAd...

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.

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

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