Posts

Post not yet marked as solved
0 Replies
325 Views
Make sure gpu capture is set to "Automically Enabled" and "Profile GPU Trace after Capture" in Xcode 12.2 and 12.4 Run an iOS app Do a GPU capture Try to go to look at Counters and they're not there. Save capture out via "Export" Reopen capture, and now Counters are there I see the "Counters" pane have a spinner for a short amount of time after doing step 2, but the Counters are never filled out. I don't want to have to exit my app to look at captures, since I need to look at multiple captures over the course of a session.
Posted Last updated
.
Post not yet marked as solved
1 Replies
398 Views
When we have warnings/errors in our make based builds, the new build system reports the warnings as relative instead of absolute paths. When I then try to click to follow to the code where the warnings/errors occur I get the "bonk" noise and Xcode doesn't take me there. My understanding is that the old build systems resolved these to full paths and so they would then jump to the line in the code, but the new build system just leaves them as a relative path. This mostly defeats the use of an IDE if we can quickly review and fix issues like this. Any suggestions for fixing this? Neither the warning/error summary, or the report navigator build panel take me to the line in FooClump.h. This is the line take from the report naviagator build pane. In file included from /Users/Me/MyAppFolder/FooClump.cpp:4: FooClump.h:30:15: warning: 'postConstructor' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]     virtual void postConstructor();
Posted Last updated
.
Post not yet marked as solved
2 Replies
539 Views
How do we get this code to not crash? This was working up until we bumped our macOS deployment to 10.15. When deployment is set to macOS 10.14, the code works fine. Data is nearly identical in the debugger, although the vtable is at a slightly lower address in 10.15. Have the C++ vtables been put in read-only marked pages, and if so how do we prevent that? Hardened runtime is not enabled, and I don't recall any mention from Apple about this change. #import Foundation/Foundation.h class Base { public: virtual ~Base() {}; virtual const char* Print() { return "Base"; } }; class Derived : public Base { public: virtual const char* Print() override { return "Derived"; } }; const char* PrintPatch( Base* localThis ) { return "Patch"; } template class T1, class T2 void* PatchVtablePtr( void** vtable, T1 memberFunction, T2 newFunction ) { // Replace the instance of memberFunction in the vtable with newFunction void* offset = *(void**)&memberFunction; auto vtableIndex = (uintptr_t)offset / sizeof(void*); vtable[vtableIndex] = (void*)newFunction; - Thread 1: EXC_BAD_ACCESS (code=2, address=0x100004038) // return the original vtable address return offset; } int main(int argc, const char * argv[]) { Derived* derived = new Derived(); printf("%s\n", derived-Print()); // monkeypatch the vtable //Base* base = derived; //void** vtable = *(void*)base; void vtable = *(void***)derived; PatchVtablePtr( vtable, &Derived::Print, &PrintPatch ); printf("%s\n", derived-Print()); return 0; }
Posted Last updated
.
Post not yet marked as solved
9 Replies
1.2k Views
We have a C++ library that we hotload on macOS. This uses dlopen() and dlclose() and worked up until recent versions of Catalina. We don't use thread_local and don't have Objective-C code in the library. dlopen() succeeds, we use the original dylib. Then for hotloading we dlclose() the original dylib and then dlopen() the new dylib. All this succeeds, and no dlerror occurs. All of the dyld output indicates that the library is being unloaded and loaded back in. But after changing the sources, and building a new dylib, the app returns the original dylib and not the new one. This seems to be a problem in the dyld layer itself, and not our sources. On older macOS builds, the hotloading works correctly. Given the lack of edit+continue in Xcode, this is the only way to iterate quickly on source code changes. How do we fix this? We are not using the hardened runtime. This is failing on macOS 10.15.7 with Xcode 12.2 (and 12.3).
Posted Last updated
.
Post not yet marked as solved
0 Replies
348 Views
I need to be able to tag each draw call with a quick string that details shader name, draw counts, etc. In Vulkan, we have pVkCmdInsertDebugUtilsLabelEXT (and begin/end event). In DX, there's Pix setMarker (in addition to begin/endEvent). And the Metal equivalent would seem to be insertDebugSignpost. But these don't appear in the Metal GPU capture at all. I also tried using a quick beginDebugGroup/endDebugGroup, but since that doesn't surround any commands, it appears to get stripped. A "marker" are needed for two reasons, quickly tagging points in code. And also to replace and flatten the begin/endDebugGroup hierarchy from folders used by "groups" when we want to do that. Why doesn't this Metal equivalent appear?
Posted Last updated
.