I have Ubuntu 22.04 (64bit) running as Guest OS in VirtualBox in my Host Win10 (also 64bit).
In Ubuntu (guest) I have the following command running:
gdbserver localhost:9999 ./application
And then in Win10 (host) I try to connect using gdb, from Mingw64:
(gdb) target remote 192.168.0.24:9999
But I encounter the following error:
warning: Architecture rejected target-supplied description
Reading <ubuntu path to folder>/application from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
warning: Architecture of file not recognized.
Reading <ubuntu path to folder>/application from remote target...
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
Reading symbols from target: <ubuntu path to folder>/application...
Remote register badly formatted: T0506:0000000000000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
here: 00000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
Both are the same architecture, so I don't understand what is going on.
The important line in the output is:
A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
This is telling you that the version of GDB you are running on the Windows host was built without support for debugging GNU/Linux targets.
This is probably why you also get this warning:
warning: Architecture rejected target-supplied description
which is GDB saying it doesn't understand the target description that the remote sent through.
As a result of rejecting the target description, GDB doesn't know the correct size for the architecture registers, which, I suspect is why you run into the error:
Remote register badly formatted: T0506:0000000000000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
here: 00000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
Notice the here: line starts with 00000000;07... this is halfway through the first register in the T packet, i.e. the remote sent 8-bytes, but GDB was expecting only 4-bytes for that register.
I suspect the solution to all your problems is to try and either install, or build yourself, a version of GDB that supports all targets, this should then include GNU/Linux support, and everything should work.
I'm building my application and source code of breakpad on Ubuntu 20.04 with two architectures (arm64 and x86_64).
Both have been built on Mac with M1 inside docker with Ubuntu 20.04 (x86_64 arch is emulated).
My build configuration:
./configure CC=clang CXX=clang++ CFLAGS="-stdlib=libc++" CXXFLAGS="-stdlib=libc++"
I'm running and provoking my app to crash in the same way in both cases (arm64 and x86_64 arch).
For x86_64 it works perfectly, I can look into generated minidump with tool minidump_stackwalk and I can see symbols from my app.
But it doesn't work for arm64. minidump_stackwalk tells me that it could't find symbols for generated minidump.
Of course in both cases I provide suitable .sym file.
Both .sym files generated for arm64 and x86_64 look fine, although I do not rule out that this file is the problem, but more probable is that problem is in generated minidump.
I also noticed that minidump (from arm64) expects symbols from my app to be in 2 separated memory ranges:
0x000000200000 – 0x0000006d3000
0x0000006e2000 – 0x0000016d6000.
The first range is a good one, and it is the same that occurs in case of x86_64.
I can assume that this is good range, cuz if I add address of function from sym file to this offset 0x000000200000 it is correct address of same function in my crash's stack trace.
Anyone has the same problem with breakpad builded for arm64 ?
Maybe I just have to figure out how to get rid of this second incorrect range saved in my minidump?
I know there are a couple of other questions about this out there, but they are not solving this problem.
Pre XCODE 7.x project, upgraded to XCODE 7.0.1
Getting the following error when linking
ld: '[deleted]/ThridParty/AmazonMobileAnalytics/AWSCore.framework/AWSCore(AWSCredentialsProvider.o)' does not contain bitcode.
You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE),
obtain an updated library from the vendor, or disable bitcode for this target. for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Even with build settings Enable Bitcode set to NO.
This is happening during ARCHIVE, but works fine for sim builds.
I am following a opencv installation document Installation in iOS when compile a ios framework. However, if I did not change platform/ios/build_framework.py and build the framework, I will have the following errors:
build settings from command line:
ARCHS = x86_64
IPHONEOS_DEPLOYMENT_TARGET = 6.0
SDKROOT = iphonesimulator6.1
Build Preparation
Build task concurrency set to 8 via user default IDEBuildOperationMaxNumberOfConcurrentCompileTasks
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT OpenCV WITH CONFIGURATION Release ===
Check dependencies
=== BUILD NATIVE TARGET zlib OF PROJECT OpenCV WITH CONFIGURATION Release ===
=== BUILD NATIVE TARGET libjpeg OF PROJECT OpenCV WITH CONFIGURATION Release ===
** BUILD FAILED **
Build settings from command line:
ARCHS = x86_64
IPHONEOS_DEPLOYMENT_TARGET = 6.0
SDKROOT = iphonesimulator6.1
=== BUILD NATIVE TARGET zlib OF PROJECT OpenCV WITH CONFIGURATION Release ===
Check dependencies
No architectures to compile for (ONLY_ACTIVE_ARCH=YES, active arch=x86_64, VALID_ARCHS=i386).
** BUILD FAILED **
Then, after many tries, I found that if I only compile for architecture armv7, armv7s and i386 by changing the following scripts in platform/ios/build_framework.py the framework can be built successfully.
targets = ["iPhoneOS", "iPhoneOS", "iPhoneSimulator"] #"iPhoneOS", "iPhoneSimulator"
archs = ["armv7", "armv7s", "i386"]#"arm64", , "x86_64"
for i in range(len(targets)):
build_opencv(srcroot, os.path.join(dstroot, "build"), targets[i], archs[i])
Any ideas on how I can compile for the arm64 and x86_64 architecture? Thanks.
Take out the i386 and compile for armv7,armv7s, and arm64 - these are the architecture option for Xcode for 64 bit - iphone5s.
Do not mix intel and arm specification they will not and cannot mix. The architecture command is to inform the compiler on how the object code will be created. Because intel is a CISC processor and arm is a RISC internally their object codes are very different.
a MOVE command for example may generate an x'80'opcode (command instruction) for intel but an x'60'for ARM. far as I know an i386 is the old intel 32 bit architecture, Xcode maybe doing some magic to have universal object codes that can run on both intel and RISC if it is doing so - it will not be efficient, it will always be better to compile to specific architectures.
The 32 bit, 64 bit 128 ..... are addressing modes - they are also the size of the processor registers and determine how much memory (RAM) can be accessed by the CPU. In general, aside from the ability to have huge RAM, higher bit processors will usually reduce the number of instructions to do a particular task.
Because downward compatibility is usually built in, an app compiled for armv6 will typically run in armv7 or even arm64 in compatibility mode but it will not be able to harness the advantages of running a true 64 bit application.
The targets is a higher level specification which specifies which commands can be used for example an iPad has UIPopViewController but this is not supported in an iPhone or an iPod touch.
One last thing - only iPhone 5s works with arm64 if you set another target it will probably flag arm64 as not an option.
So if you are compiling for x86_64 architecture, that is for OS X (laptop or mac tower), NOT iOS (iPad, iPhone).
What are you using? Not Xcode I presume?
You don't need to compile to x86_64 unless you want this to run on a 64-bit mac laptop or desktop... & it doesn't seem like you are trying to do that by your question?
Also, if you have it for i386 it is probably compatible with most OS X machines -- it will just run in 32-bit not 64-bit.
As far as arm64, that is also probably 64-bit. You might not have the libraries for 64-bit? Is your machine running on 64-bit? Check the opencv libraries (dynamic or static?) & see if they are 32 or 64? If they are 32-bit then that is the problem. You'll need to build them as 64-bit libraries or find them as such. I can't give you anymore info without knowing what platform you are on.
I recently learned that OpenCV for iOS has been added to CocoaPods. You can see the podspec here and the Github repository here. With CocoaPods, you create a file named Podfile in the root of your project and paste in this line:
pod 'OpenCV'
Save the file and run pod install from the terminal (assuming that CocoaPods is installed of course).
I have this running on my iPhone 5S, which is 64 bit as well.
After successfully building binutils/ld with mingw and trying to run it I am getting this message-
$ ld-new
h:/binutils-2.23.1/ld/.libs/ld-new.exe: unrecognised emulation mode:
Supported emulations:
I've looked through the internals documentation and from what I understand you need to set up the configure or makefile so that the emulation mode you want is installed during the build process but I can't work out how you actually do that.
Would appreciate it if someone could explain the process.
Thanks very much.
It seems that default emulation mode is determined based on target tuple that is provided to binutils configure script (--target option).
See also: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/configure.tgt;hb=HEAD