objdump seems to always print an error message, example: malcolm@Malcolms-Air keeperfx % objdump --version Apple LLVM version 13.0.0 (clang-1300.0.29.30)  Optimized build.  Default target: arm64-apple-darwin21.3.0  Host CPU: vortex  Registered Targets:   aarch64  - AArch64 (little endian)   aarch64_32 - AArch64 (little endian ILP32)   aarch64_be - AArch64 (big endian)   arm    - ARM   arm64   - ARM64 (little endian)   arm64_32  - ARM64 (little endian ILP32)   armeb   - ARM (big endian)   thumb   - Thumb   thumbeb  - Thumb (big endian)   x86    - 32-bit X86: Pentium-Pro and above   x86-64   - 64-bit X86: EM64T and AMD64 malcolm@Malcolms-Air keeperfx % clang --version Apple clang version 13.0.0 (clang-1300.0.29.30) Target: arm64-apple-darwin21.3.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin malcolm@Malcolms-Air keeperfx % clang -c src/actionpt.c In file included from src/actionpt.c:19: In file included from src/actionpt.h:22: src/bflib_basics.h:153:15: warning: '__stdcall' calling convention is not supported for this target [-Wignored-attributes] typedef void (__stdcall *TbNetworkCallbackFunc)(struct TbNetworkCallbackData *, void *);        ^ 1 warning generated. malcolm@Malcolms-Air keeperfx % objdump -f actionpt.o  actionpt.o: file format mach-o arm64 /Library/Developer/CommandLineTools/usr/bin/objdump: error: 'actionpt.o': Invalid/Unsupported object file format The warning message should have no impact on objdumps ability to produce a result. I have been looking for objcopy as I need to rename some functions in a precompiled library. I installed the gnu binutils version (brew install binutils) .. this generates a file that the gnu binutils thinks is perfect. The Apple objdump throws up error messages.

I just bought a new m1 pro MBP, and it takes a lot of time to build any project after downloading Xcode from the App Store, such as this https://github.com/devMEremenko/XcodeBenchmark. It takes 30 minutes, and my old intel mac only takes 3 minutes. What should I do? Xcode Version: 13.2.1

How to deduce from NSMethodSignature that a struct argument is passed by pointer? Specifically on ARM. For example if I have: @protocol TestProtocol <NSObject> - (void)time:(CMTime)time; - (void)rect:(CGRect)point; @end And then I do: struct objc_method_description methodDescription1 = protocol_getMethodDescription(@protocol(TestProtocol), @selector(time:), YES, YES); struct objc_method_description methodDescription2 = protocol_getMethodDescription(@protocol(TestProtocol), @selector(rect:), YES, YES); NSMethodSignature *sig1 = [NSMethodSignature signatureWithObjCTypes:methodDescription1.types]; NSMethodSignature *sig2 = [NSMethodSignature signatureWithObjCTypes:methodDescription2.types]; const char *arg1 = [sig1 getArgumentTypeAtIndex:2]; const char *arg2 = [sig2 getArgumentTypeAtIndex:2]; NSLog(@"%s %s", methodDescription1.types, arg1); NSLog(@"%s %s", methodDescription2.types, arg2); The output is: v40@0:8{?=qiIq}16 {?=qiIq} v48@0:8{CGRect={CGPoint=dd}{CGSize=dd}}16 {CGRect={CGPoint=dd}{CGSize=dd}} Both look similar, no indication that CMTime will be actually passed as a pointer. But when I print the debug description: NSLog(@"%@", [sig1 debugDescription]); NSLog(@"%@", [sig2 debugDescription]); The first prints: ... argument 2: -------- -------- -------- -------- type encoding (^) '^{?=qiIq}' flags {isPointer} ... While the second prints: ... argument 2: -------- -------- -------- -------- type encoding ({) '{CGRect={CGPoint=dd}{CGSize=dd}}' flags {isStruct} ... So this information is indeed stored in the method signature, but how do I retrieve it without parsing the debug description? Are there rules I can use to deduce this myself? I tried to experiment with different structs but it is hard to spot a pattern.

Hi, What could be causing this on Monterey (M1 Max)? How to debug further? Reproduction steps filed in https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/301 0 0x104768224 __assert_rtn + 128 1 0x10476e4e8 ld::tool::OutputFile::addDyldInfo(ld::Internal&, ld::Internal::FinalSection*, ld::Atom const*, ld::Fixup*, ld::Fixup*, ld::Fixup*, ld::Atom const*, ld::Atom const*, unsigned long long, unsigned long long) (.cold.1) + 0 2 0x1046b0b98 ld::tool::OutputFile::addDyldInfo(ld::Internal&, ld::Internal::FinalSection*, ld::Atom const*, ld::Fixup*, ld::Fixup*, ld::Fixup*, ld::Atom const*, ld::Atom const*, unsigned long long, unsigned long long) + 0 3 0x1046a3544 ld::tool::OutputFile::generateLinkEditInfo(ld::Internal&) + 1188 4 0x10469da90 ld::tool::OutputFile::write(ld::Internal&) + 140 5 0x10462b1d8 main + 584 A linker snapshot was created at: /tmp/libHSfuturice-integrations-0-inplace-ghc8.10.7.dylib-2022-00-08-222023.ld-snapshot ld: Assertion failed: (target->definition() != ld::Atom::definitionProxy), function addChainedFixupLocation, file OutputFile.cpp, line 5903. clang-12: error: linker command failed with exit code 1 (use -v to see invocation) `clang' failed in phase `Linker'. (Exit code: 1)

Since we upgraded a Mac to the latest Xcode (coming from 12.4) to 13.1 or 13.2.1 / commandline tools 13.2 we're hitting an error when linking our executable. clang: error: unable to execute command: Bus error: 10 clang: error: linker command failed due to signal (use -v to see invocation) ninja: build stopped: subcommand failed. It only happens when doing LTO builds. I disabled system hardening to be able to attach LLDB to the linker hoping to find more info on why it might crash and got a huge stack trace:   * frame #0: 0x00000001058087d0 libLTO.dylib`computeKnownBitsFromOperator(llvm::Operator const*, llvm::APInt const&, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) + 32   frame #1: 0x00000001057f6333 libLTO.dylib`computeKnownBits(llvm::Value const*, llvm::APInt const&, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) + 1523   frame #2: 0x00000001057f5cc9 libLTO.dylib`computeKnownBits(llvm::Value const*, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) + 169   frame #3: 0x00000001058097cd libLTO.dylib`computeKnownBitsFromOperator(llvm::Operator const*, llvm::APInt const&, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) + 4125 total stack size is 24824 frames. There is a clear loop pattern here so either this triggers an endless loop causing the stack to get exhausted or we have something in our code that triggers this deepdive that eventually might resolve when stack room would be a plenty. It actually looks to be the latter as we have a similar issue on Linux compiles which we fixed by changing the ulimit -s 16384 but that command seems to change absolutely nothing on the mac I'm working on. After changing this in the bash shell (users default shell) it still remains a stack of 24824 frames. Working here on: Mac OS Monterey 12.1 Mac Pro (2019) - 2.5 GHz 28-Core, 96GB RAM ld -v : @(#)PROGRAM:ld PROJECT:ld64-711 BUILD 21:57:11 Nov 17 2021 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 13.0.0, (clang-1300.0.29.30) (static support for 27, runtime is 27) TAPI support using: Apple TAPI version 13.0.0 (tapi-1300.0.6.5)

lldb-rpc-server_2022-01-01-210548_Aamors-MacBook-Pro.crash

Currently in Xcode 13, clang static analyzer is not analyzing Swift Language. Will Clang Static Analyzer eventually support Swift Language in the upcoming releases?

Where can I find a list of all the effects that will happen based on my app's IPHONEOS_DEPLOYMENT_TARGET setting? In "App Startup Time: Past Present and Future" at WWDC 2017, Apple told us that "in a future iOS version" there would be additional restrictions that dyld places upon your app, based on its minimum supported OS setting. I've also seen mentions in various WWDC talks and Xcode patch notes about certain compiler settings & optimizations that are only applied to apps targeting iOS Z or higher, where Z is some version. However I cannot seem to find a comprehensive list of ALL the ways your app will be treated differently based solely on the minimum support OS setting that you list in your Info.plist. The reason I ask is because one of the apps I work with has been experiencing crashes when we set the IPHONEOS_DEPLOYMENT_TARGET to 14.0 instead of 13.0, but nothing else is different. So there must be some difference in how our app is being compiled or signed, or what restrictions are placed on it, based solely on the minimum supported OS. But for the life of me, I cannot find a comprehensive list of the things that come into effect based on the minimum supported OS. In particular, I need to know all the particular effects that are different between compiling for a minimum supported OS of 13.0 and 14.0, besides the obvious things like: now you can use iOS-14-specific APIs without an availability check now your app won't run on an iOS 13 device Besides that, there are obviously some additional differences that come into play. One that I can think of is that when built with Xcode 13 and iOS 15 SDK or later, and a minimum supported OS of 14.0 or later, the following compiler flag is enabled by default: The new -fobjc-constant-literals flag lets you declare declare global constant literals, and performs optimizations for other literals it supports in Objective-C code. You can use this flag to embed static property list literals (NSDictionary, NSNumber, and NSArray) at compile time, placing them in the CONST section of the binaries. (44920795, 45380392) However the crashes we're seeing happen even if the app is built with Xcode 12.5, which doesn't support that new flag, so I don't think that it could be related to this compiler flag. I've also been able to find some places in OpenSource.apple.com in the latest dyld source-code that take the minimum supported OS as a parameter, but I can't tell if it's being used to apply stricter checks to the app or not. Any help would be appreciated, even if it's just to mention one or two things that you're aware of which take effect based on a minimum supported iOS/iPadOS of 14.0.

This time I upgraded xcode 12.3 -> 13.1. The project code is c/c++ library code. When compiling after upgrade, basic system header files such as errno.h and unistd.h, string.h ... cannot be referenced. The code uses c api a lot instead of c++ api. (std::string -> char *, memcpy, memset etc.) How to solve it? must upgrade because of iPhone live debugging. env os : monterey 12.0.1 xcode : 13.1 error message: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:73:64: Use of undeclared identifier 'strchr' /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdlib.h:148:12: No member named 'lldiv' in the global namespace /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:80:75: Use of undeclared identifier 'strpbrk' /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:94:76: Use of undeclared identifier 'memchr' ...

When I set the icon for a file using[[NSWorkspace sharedWorkspace] setIcon: myImage forFile: [[sheet URL] path] options: NSExcludeQuickDrawElementsIconCreationOption];2019-11-21 14:34:44.954590-0700 Appname[4856:152311] [default] Invalid image size X: 1024 Y: 1152XCode 11.2.1 correctly sets the file icon to myImage but logs the error 14 times. This didn't happen in older versions of XCode. The Developer Documentation doesn't say anything about any particular requirements for the size if the NSImage. Setting the the options to either one of the two options doesn't change the error. Is this a spurious error? Am I missing something. Should I file a bug report?

I've got an iOS framework that I've had around for ages. It's a mixture of Objective-C and Swift. Since installing Xcode 12, I'm now getting a bunch of warnings of the type: 'Double-quoted include in framework header, expected angle-bracketed instead' If I go to the various source files and say change: #import "Place.h" to #import &lt;VegasKit/Place.h&gt; then I get an error saying it can't find the file. If I try this: #import &lt;Place.h&gt; then I get an error telling me to go back to double-quotes, i.e. undo the change. Any idea what I can do to get this all setup correctly? Thanks.

Hi there, Currently we are developing a dynamic library written in C++, target to run on arm64 ios. Things become wired when we try to archive the final project. It says, bitcode bundle could not be generated because 'the_path_to.dylib' was built without full bitcode. Some brief arch of this project lists below, we use cmake and this toolchain to build this dylib. It has an argument named ENABLE_BITCODE. It would append -fembed-bitcode to C_FLAGS & CXX_FLAGS. BTW, we use clang & clang++ as C and C++ compiler. this dylib has several dependencies, such as libcurl, libffi. We download them from vcpkg then build with bitcode enabled. As mentioned above, running it directly on the phone works as we expected. But we can't archive it. using otool -l the_path_to.dylib | grep bitcode shows nothing. We still want to make it support bitcode feature. Is there anything we miss to do to enable this? About bitcode, is there anything to learn? Is there an accurate way to find out that the dylib support bitcode or not? Thanks in advance.

I'm using Apple Clang on macOS 11.5.2. When I try to compile the following code: #include <fstream> #include <iostream> #include <filesystem> int main() { const std::filesystem::path sandbox{"sandbox"}; std::ofstream{sandbox/"file1.txt"}; std::ofstream{sandbox/"file2.txt"}; std::cout << "directory_iterator:\n"; for(auto const& dir_entry: std::filesystem::directory_iterator{sandbox}) std::cout << dir_entry << '\n'; std::filesystem::remove_all(sandbox); } Via the command clang++ foo.cpp -std=c++17 , I get: foo.cpp:13:19: error: invalid operands to binary expression ('std::__1::ostream' (aka 'basic_ostream<char>') and 'const std::__1::__fs::filesystem::directory_entry') std::cout << dir_entry << '\n';

Hello Team, I am facing the clang error when I am trying to run the source in Xcode 12.5 BUT it is working fine in 11.4 In file included from :1: PrefixHeader.pch:15:2: fatal error: malformed or corrupted AST file: 'mismatched umbrella headers in submodule' #import &lt;FAPL/FAPL.h&gt; ^ clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-ios10.0-simulator Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: error: unable to execute command: Segmentation fault: 11 clang: note: diagnostic msg: Error generating preprocessed source(s).

As you may know libc++ on MacOS is using weird implementation of RTTI: it compares typeinfo objects by pointers instead of comparing name-strings (like it happens in standard runtimes on Windows and Linux). Since each module has its own typeinfo instance - dynamic_cast for polymorphic types and exception handling may not work across module boundaries if you use -fvisibility=hidden and/or two-level namespace (At the runtime you will either get error from dynamic_cast, or fail to catch exception that was thrown from another module). The problem is that sometimes we have ODR violations because of legacy code, and sometimes there are reasons to legally violate ODR and define same typeinfo in multiple modules - templated polymorphic type. To make polymorphic types work across modules we must make sure that our typeinfo symbols are coalesced (merged) across these modules. This is why I started investigating the way symbols are coalesced on MacOS, my observations so far: For dylib compiled with -flat_namespace everything seems to work as in linux - strong definition in our dylib is overridden by strong definition from another dylib only if another dylib is loaded before ours and both definitions are visible, another library might be compiled with two-level namespace. Weak definitions can be overridden by other weak definitions or strong definition. For dylib compiled with two-level namespace (default and recommended mode) strong symbol definitions cannot be overridden, so there is no way to merge strong typeinfos (these are normally defined for non-templated polymorphic classes). At the same time typeinfo of templated is represented as weak definition, which gets overridden by any previous definition of typeinfo in process, if another dylib with strong/weak visible definition is loaded before our dylib. Questions (sorry for 3 questions at once, but I am really confused): Is there any way to override/coalesce strong symbol definition when this definition is in dylib built with two-level namespace? In the example below this would mean calling sharedlib::Print of main.cpp from libsharedlib.dylib. This works in flat_namespace mode, but not in two-level namespace. Maybe I am missing something. What is the point of two level namespace if weak definitions of my dylib can be overridden by any bad implementation from customer's process? I thought two-level namespace was supposed to protect my dylib from picking up unexpected symbol definitions (for example from another boost version used in process of my customer), but it seems this expectation is not holding up for templated polymorphic classes, and for all weak symbols in general. Is there any common way to handle issue with multiple typeinfos on MacOS? I think one of solutions would be to use -fvisibility-ms-compat and -flat_namespace, which is basically -fvisibility=hidden + it makes all vtables and typeinfos visible, -flat_namespace makes sure all typeinfos for the same types are merged into one by dynamic linker. The problem with this approach is that it seems hacky, and it also makes typeinfo and vtable of some boost header-only classes to be visible in our dylib. I am afraid we can break customer's process if at some point these boost classes change order of methods, or change set of methods (therefore vtable will become incompatible). If you want to play with example, here it is: templates.hpp: #pragma once namespace Foo { template<typename T> class Bar { public: Bar(){}; virtual ~Bar(){}; virtual void SetValue(const T& v) { m_value = v; } T m_value; }; } main.cpp: #include <typeinfo> #include <cstdio> #include "templates.hpp" namespace sharedlib { void CheckTemplate(const Foo::Bar<double>& b); void __attribute__ ((visibility ("default"))) Print() { printf("Print from main executable\n"); } } int main(void) { Foo::Bar<double> b; sharedlib::CheckTemplate(b); return 0; } sharedlib.cpp: #include "templates.hpp" #include <typeinfo> #include <cstdio> namespace sharedlib { void __attribute__ ((visibility ("default"))) Print() { printf("Print from sharedlib\n"); } void __attribute__ ((visibility ("default"))) CheckTemplate(const Foo::Bar<double>& b) { printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(b))); Foo::Bar<double> localB; printf("&typeinfo=%p\n", static_cast<const void*>(&typeid(localB))); Print(); } } Makefile: check: ./main all: main sharedlib main.o: main.cpp clang++ -fvisibility-ms-compat -c main.cpp sharedlib.o: sharedlib.cpp clang++ -fvisibility-ms-compat -c sharedlib.cpp sharedlib.dylib: sharedlib.o clang++ sharedlib.o -dynamiclib -o libsharedlib.dylib # If you use flat_namespace, sharedlib::Print will be replaced by sharedlib::Print defined in main.cpp #clang++ sharedlib.o -dynamiclib -Wl,-flat_namespace -o libsharedlib.dylib main: main.o sharedlib.dylib clang++ main.o -L. -lsharedlib -o main clean: rm -rf *.o *.dylib main Some commands to check results: # check if TWO_LEVEL namespace is used by the dylib otool -Vh ./sharedlib.dylib # check all symbols nm -om ./libsharedlib.dylib | c++filt # output: ... ./libsharedlib.dylib: (undefined) external std::terminate() (from libc++) ./libsharedlib.dylib: 0000000000004040 (__DATA_CONST,__const) weak external typeinfo for Foo::Bar<double> ./libsharedlib.dylib: 0000000000003f70 (__TEXT,__const) weak external typeinfo name for Foo::Bar<double> ... # ld verbose mode, to see how coalescing happens: DYLD_PRINT_BINDINGS=1 ./main

Hey guys, I am trying to compile C++ code on Mac using command line tools(g++) to output a static library(.a). I compiled it with architecture support for arm64, however when I link it in Xcode project I get the following error Building for iOS but linked library was built for MacOS I have used following command g++ -shared -o ./libCrossPiOS_TestMulti.iOS.a ./alpha.cpp -arch arm64 I understand that I can choose XCFrameworks route to get past this but wanted to understand what I'm missing in this approach. Any help will be appreciated. Thanks in advance Screenshot of error

https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/working_with_core_foundation_types If we define a C function that returns a CFType, Swift can (sometimes) bridge the memory management semantics. If Swift cannot bridge the memory management semantics, we can end up with an Unmanaged type: CFStringRef StringByAddingTwoStrings(CFStringRef s1, CFStringRef s2); bridges to: public func StringByAddingTwoStrings(_ s1: CFString!, _ s2: CFString!) -> Unmanaged<CFString>! We can improve the bridging with the CF_RETURNS_RETAINED annotation: CFStringRef StringByAddingTwoStrings(CFStringRef s1, CFStringRef s2) CF_RETURNS_RETAINED; now bridges to: public func StringByAddingTwoStrings(_ s1: CFString!, _ s2: CFString!) -> CFString! What does not seem to be documented is how to improve bridging when function pointer return values should be annotated. For example: typedef CFStringRef (*StringByAddingTwoStrings)(CFStringRef, CFStringRef); bridges to: public typealias StringByAddingTwoStrings = @convention(c) (CFString?, CFString?) -> Unmanaged<CFString>? Is there any way to annotate the function pointer to properly communicate the memory management semantics? Adding the CF_RETURNS_RETAINED to the function pointer does not seem to help.