I have observed kernel panic. To identify at which line kernel panic observed, I have followed last method (Using GDB to find the location where your kernel panicked or oopsed.) in the link.
I have used arm cross tool chain gdb, as the target is ARM board. But it is giving "No symbol table is loaded. Use the file command." error. I tried to load symbol table using "file System.map" , but it is giving "System.map: not in executable format: File format not recognized" error.
Can you help to address this symbol table issue. The host PC is running with Ubuntu 12.04.
Related
I receive the error:
.../Base.lproj/MainMenu.xib Failed to render instance of : dlopen(....app, 0x0001): tried: '/...' (no such file), '....app' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS....app' (no such file), '....app' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))`
when loading my .xib. Where <MyView> stands for the name of my derivated NSView and the ... for my application name.
There are quite a number of reports with this or a similar issues when the 1st M1 processors were on the market as:
(Xcode 12 Apple M1 arm64 - Designable error: "wrong architecture") or
(IBDesignable Build Failed) and more. Most of them add some pathes to the LD_RUNPATH_SEARCH_PATHS under "Linking".
None of the solutions given there were helpful for me, but I found a link where you could change the arch under which the Terminal should run.
see
Partly solved:
Now after opening my .proj file and when I receive this error, I open the Terminal.app, switch it to Intel and then back to Arm (leaving the terminal window open) and voila the IB preview displays correctly. See result here
Concerning XCode this is a regression, since under Intel Xcode 11 this always was working correctly.
Anybody knows, what is happening or how to avoid this inconvenience?
the formatting now is not ok. The error message ends with
.../Base.lproj/MainMenu.xib Failed to render instance of :
dlopen(....app, 0x0001): tried: '/...' (no such file), '....app'
(mach-o file, but is an incompatible architecture (have 'x86_64', need
'arm64')), '/System/Volumes/Preboot/Cryptexes/OS....app' (no such
file), '....app' (mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64'))
I'm trying to compile the sysvad audio driver example found here: https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad
Getting a linker error when compiling windows kernel mode driver x64
error LNK2019: unresolved external symbol __stdio_common_vswprintf referenced in function _vsnwprintf_l
Apparently my VC paths are jacked up, but i have tried many things, and cannot find where this lives. I have tried adding libucrt.lib but that gives me a different error:
warning LNK4257: object file was not compiled for kernel mode; the image might not run
Everything compiles fine for Win32 version.
Using the new Xcode 8 GM build on the GM of macOS Sierra, I've recompiled a Qt 5.7 C++ project and I'm getting the following error message when trying to launch the app:
Reason: no suitable image found. Did find:
/path/to/my/lib/libio_core.dylib:
malformed mach-o image: symbol table underruns __LINKEDIT
This doesn't occur on debug builds, only release. Does anyone have an idea as to what this means and how to go about fixing it?
Update:
This actually has nothing to do with Xcode 8. Building the same code with Xcode 7.3.1 results in the same outcome. It seems some apps that ran just fine on El Capitan won't run on Sierra and fail with the above error.
Update 2: Details about the symbol table in my binary:
Load command 5
cmd LC_SYMTAB
cmdsize 24
symoff 0
nsyms 0
stroff 12760
strsize 8
Turns out this was caused by Qt. Qt 5.7.0 calls strip with no arguments when performing the install task on libs. With macOS Sierra this results in a dylib with an empty symtab.
This bug will be fixed in Qt 5.7.1. In the meantime, just make sure you call strip with -S -x for dynamic libraries.
I am seeing a similar error and I have just figured it out in my case. I hope what I found will help you too.
So, basically, as far as I can tell, this happens when your binary has an empty symbol table (there might be other cases, though). You can check this by running objdump -private-headers <library>:
<...>
Load command 4
cmd LC_SYMTAB
cmdsize 24
symoff 0
nsyms 0 <-- no symbols, oops
stroff 4104
strsize 8
<...>
Linker believes that if the symbol table is empty (nsyms 0) it is ok to say that the offset of the table into the file is zero (symoff 0). So, strictly speaking, it claims that the table starts right at the beginning of the binary.
Apparently, the new version of dyld from 10.12 Sierra performs a check that previous versions did not perform: it makes sure that the symbols table is entirely within the __LINKEDIT segment. Well, in our case the symbol table clearly violates this constraint and dyld does not care that it is empty.
I would call this an Apple’s bug: their linker creates malformed binaries and doesn’t bother to even issue a warning. If I were Apple, I would modify the condition in dyld to ignore the symbol table constraint if the symbol table is empty.
There is only one workaround I can see: add a dummy symbol to your reexport library.
I want to try out RInside for Mac OSX. I downloaded RInside from source using Terminal and then went into the /inst/examples/standard and tried to run make, as indicated in the answer to this thread: RInside on Mac OS X
However, the first error I received was fatal error: 'RInside.h' file not found. I manually found this file and put it into the /inst/examples/standard directory and ran make again. I received another fatal error for another .h file so I manually found the requisite file and inserted it into this standard directory. Anyway, after doing that a few more times, all dependencies were taken care of, then I ran make again and received the following very strange error:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I also tried using clang++ -stdlib=libstdc++ in place of g++ (since RInside on Mac OS X says that g++ won't work), but it did not help either (i.e., I received the same architecture errors).
I am stuck here...
UPDATE:
As per Dirk Eddelbuettel's advice, I tried installing XTools (Run Windows X System on OSX), but I received the following error: "Xtools.pkg" is damaged and can't be opened. You should eject the disk image."
I am concerned that running a simple "hello world" script as provided on the RInside webpage (http://dirk.eddelbuettel.com/code/rinside.html) can be this convoluted on the Mac as to demand external installs and miscellaneous configurations. Hence, there must be a more straightforward way to run RInside on the Mac OS X.
I am trying to use CIL merger to merge Linux Kernel and run an analysis on it.
I tried this on different version of the kernel. each gave different errors.
Linux-3.4.2:
In Linux Kernel-3.4.2 source folder I used the following command
$ make CC="cilly --save-temps --dofsvd --merge"
and it gave the following error
/home/srikanth/projects2test/linux-3.4.2/arch/x86/include/asm/cpufeature.h[345:0-0]
: syntax error Parsing errorFatal error: exception
Frontc.ParseError("Parse error")
error is due to this line:
asm goto(... : : "i" (bit) : : t_no);
It is unable to recognize the "asm" instructions. I googled for it. In BLAST bug reports (here) I found that we can use some aspectator options to prevent such constructs. But I don't know what options to use. How can I Ignore asm(or any other constructs that are not supported)?
Linux-2.4.5:
In Linux Kernel-2.4.5 source folder I used the following command
$ make CC="cilly --save-temps --dofsvd --merge"
The above command gave the following error
Makefile:229: arch/x86_64/Makefile: No such file or directory make:
* No rule to make target `arch/x86_64/Makefile'. Stop.
for this I included ARCH=i386 option to make file.
$ make ARCH=i386 CC="cilly --save-temps --dofsvd --merge"
and it said
init/main.c:1:0: error: CPU you selected does not support x86-64
instruction set
How to fix this error?
I want to run the analysis on Linux Kernel (any version). I am unable to merge it due to these errors. please help me fix these problems.