I'm trying to evaluate a Mach-O object file by running idal -b <mach.o> from within another program and working with the .idb produced. But I'm having troubles with this.
By running idaq a few times and toggling some options, I've found that the issue is with the 'Load DWARF debug information' option. If I select yes, the disassembly is poor - it's almost all considered data. If I select no, the disassembly looks as I'd expect.
The result from idal -b <mach.o> looks like the result where the DWARF debug information has been loaded.
So I'm looking for a way to toggle off the loading of the DWARF info programatically. Is there a command-line option or something I can put in a config file somewhere when I'm evaluating a Mach-O file? I would like the behavior to remain as-is if I'm evaluating an ELF object file, so I don't want to use the 'don't ask me again' option in the GUI prompt.
I'm running IDA Pro 6.5 on Ubuntu 14.
Related
My apology for the "newbie trouble" that I created for myself & apology for my poor command of computer lingo
I am running a Windows 7 laptop and have a big text file (~4Gb) that I need to find certain string.
Most programs in Windows 7 cannot handle the task (file too big to open in any program in the Microsoft suite), so I downloaded cygwin and tried to grep the specific string.
The problem is
(a) the 4 Gb file is stored in the desktop of my non-admin account.
(b) I assume cygwin runs in the admin account (although I use the desktop cygwin icon to launch the environment). The reason being that under cygwin, I see the handle A#Admin-THINK (running it on a Lenovo Thinkpad laptop)
grep the file of interest results in "No such file or directory"
I tried to find the path of the file (readlink, realpath) but guess the commands were not applicable here?
Also tried /home/A/file or /home/A/desktop/file but it is clear that my random guess fails.
From windows, the file should be in
C:/Users/non_admin/desktop/folder/file
What would be the right path of the file to grep the string using cygwin ?
You can use /cygdrive to access the Windows filesystem. In your case, try
grep foo /cygdrive/c/Users/non_admin/Desktop/folder/file
From windows, you can get the correct file path from the context menu item Copy as path into the copy/paste buffer.
In Cygwin mintty, use
FilePath=<paste>
where <paste> means to use paste from mintty's context menu to make a variable with the value of that path.
Then use
grep <string> $(cygpath -u "$FilePath")
to search the file. The "'s are in case the file name contains spaces.
HTH
I have tried a lots of advice to help to set up the CDB debugger in Qt Creator but when using it that thing still takes ages to load up local variables.
My setup:
Windows 10 64-bit
Qt 5.6 (installed with sources)
Qt Creator 3.6.1
Microsoft Visual Studio 14 (2015) (both 32-bit and 64-bit compilers)
Windows SDK (for debugging tools = CDB)
The General tab in Options->Debugging lists auto-detected sources:
Source: Q:/qt5_workdir/w/s
Target: C:\Qt\5.6\Src
My symbols server and cache are set up in CDB Paths like this:
srv*http://msdl.microsoft.com/download/symbols
cache*C:\Qt\CDB-symbols-cache
On first run of the debugger it populates this directory with 70mb of (presumably downloaded) data but it does not seem to change afterwards on subsequent runs.
I suspect either the sources being loaded takes a long time (although I have a SSD) or that the CDB is re-downloading the symbols instead of using the cache. Any advice?
EDIT: As per request, result of .sympath command on my system:
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred
srv*
I had the same problem with QtCreator 4.12 which was solved by removing AppData\Roaming\QtProject\default.qws as suggested by Abstraction in the comments above.
I had the same issue with QtCreator 4.0.2 and VS 2015. Here is what I did.
Downloaded the microsoft symbol package from symbol packages
Copied it to a local folder(D:\Symbols)
In QtCreator , Tools->Options->Debugger->CDB Paths select "Insert Symbol Server" and select the local folder. Will look like the below screen.
I tried all the above and did not worked, however one thing worked: renaming the file default.qws
Usually it would take 10 seconds to load the debugger and it went to 10 minutes. Analyzing deeper I found out that the problem is with the breakpoints: if a breakpoint is on a file which is not part of the project, the debugger attempts to resolve the breakpoint for each loaded module/DLL, making the process incredibly slow.
The solution is to edit the file default.qws and remove those breakpoints which are set to files that don't exists anymore and you will get the speed as before.
So I just messed up real bad.. I'm hoping someone can tell me I didn't just ruin everything I did for the last 4 weeks with this simple typo..
I kept making changes to my C program and would recompile to test the changes using this in terminal:
gcc -o server server.c
Due to programming for the past 5 hours straight for the most part.. I accidentally typed this the last time I tried compiling:
gcc -o server.c server
I got some long message and realized my mistake.. tried recompiling using the first way I listed.. And it says "no such file server.c"
I typed "ls" and sure enough.. my program isn't there.
Please tell me everything I did hasn't vanished? :((
Unfortunately, you told the compiler to read your executable, and write its output to your source file. The file is gone. If you are on a Windows system, perhaps it could be undeleted with something like Norton Utilities. If not, you're probably out of luck.
Next time, consider using a Makefile to contain the compiler commands, so you can just type "make" to build your program. Other strategies include keeping the file open in a single editor session the whole time you're working, and using a source control system like git or subversion (which would let you back up to previous versions of the file, as well.)
I am trying to set ignorecase by default in my vim environment.
Curently, ~/.vimrc doesn't exist. When I open vim and use :scriptnames to see what scripts are loaded, I have a bunch of *.vim files loaded.
When I create my own ~/.vimrc containing only:
set ic
I get the following error:
E216: No such group or event: SpellFileMissing * call
spellfile#LoadFile(expand('')) Hit ENTER or type command to
continue
when opening vim. When I use :scriptnames to see what scripts are loaded again, on top of the list is my '.vimrc' file followed by all the same '*.vim' files as before...
Why would this happen?
Thanks...
P.S. I am using vim version 6.3
This looks like a mismatch of (newer) Vim runtime files and your ancient Vim version; the SpellFileMissing event is related to spell checking, which was introduced in Vim 7.0. You seem to have runtime files that initialize the (non-existing) spell checking.
Upgrading Vim looks like the easiest and best way to resolve this.
Vim 6.3 is from 2004 and very outdated. It should be possible to install the latest version 7.3; if you can't find a proper package for your distribution (for Windows, check the binaries from the Cream project, it's also not very difficult to compile (e.g. from the Mercurial sources) on Linux.
I installed Windows 10 (64bit). Since then, Isabelle HOL is no longer starting, even after a re-installation (which ran through smoothly). The error message is the following: "Startup Error: Error starting Java VM". This happens with the two versions I tested (2013-2 and 2015).
The jvm.dll which is specified in the configuration file, exists in the right folder. Additionally, I have installed Java SDK in newest version (8.51) in both, 32bit and 64bit.
Is there a known compatibility problem with Windows 10? Isabelle used to work with Windows 7 and 8.
Thank you for you help.
Update (150822)
From the developer's mailing list, there's a link to a test release:
NEWS: updated to jdk-8u60, with support for x86_64-windows
www4.in.tum.de/~wenzelm/test/Isabelle_21-Aug-2015
That's working different from Isabelle2015, in how it does some things with paths, so it might find the things it needs for Windows 10, or it may not. However, even if it works, there may be some incompatibilities with Isabelle2015 (in theorem proving).
Regardless, Isabelle only gets released 1 to 2 times a year, and I wouldn't expect anything special to be released for Windows 10 within 4 to 6 months. The links above, though, show that M.Wenzel can package together a test release, but he mainly operates on the user's mailing list.
In my batch file below, I set HOMEDRIVE and HOMEPATH, which you don't need if you want .isabelle to be in C:\user.
In this test release, those settings don't affect my home path. It also appears that USER_HOME is used, though my setting of USER_HOME doesn't make my batch file work for this test release.
Anyway, this test release has changed the way it works to discover things, and accomodates Windows even more, as shown by the new behaviour of the function File.platform_path.
It's working different enough, and requires enough changes, that I should stay with Isabelle2015, or I'll be out of sync with the official release.)
Original
(Zeroeth: Problems like this generally get hashed out on the mailing list, but I go ahead show you how I start Isabelle using a batch file, which I started doing before I had to start doing it.)
First, the Java that Isabelle uses is in this folder:
Isabelle2015\contrib\jdk\x86-cygwin\jre
Doing a normal Java install for Windows is not going to change which Java that Isabelle uses.
Below, I give you a batch file and bash file to start Isabelle/jEdit, which is an alternative to using Isabelle2015\Isabelle2015.exe.
For myself, what I've done is manually replace the 32-bit jre folder shown above with the jre in jre-8u45-windows-x64.tar.gz. (I renamed the old 32-bit folder. The most recent Java tar files can be found at the download page.)
Consequently, if I try to start up Isabelle with Isabelle2015.exe, I also get a popup that says, "Startup Error, Error starting Java VM", but starting Isabelle with the batch/bash combination works for me on Windows 8.1.
What I show you below may not fix your problem, but I guess Isabelle2015.exe has to get some info from the OS to work right, and maybe that's changed with Windows 10:
https://lists.cam.ac.uk/mailman/htdig/cl-isabelle-users/2014-December/msg00033.html
You put the batch and bash file below in the folder that you have or want your .isabelle folder. Change ISAHOME below to where your Isabelle distribution is. PATH needs the Cygwin bin in the path, and the path for isabelle, which I set in the batch file.
FILE: start-isabelle.bat
:: Isabelle2015.exe uses these directly. Setting HOME or USER_HOME doesn't work
set HOMEDRIVE=%~d0
set HOMEPATH=%~p0
:: Cygwin uses HOME, and this is how HOME is set in Cygwin-Terminal.bat
set HOME=%HOMEDRIVE%%HOMEPATH%
:: ADD PATHS: 'cygwin/bin' to start terminal, 'Isabelle2015/bin' for 'isabelle'
set ISAHOME=E:\E_2\d ev\Isabelle2015
set PATH=%PATH%;%ISAHOME%/contrib/cygwin/bin;%ISAHOME%/bin;
set CHERE_INVOKING=true
::MINTTY CONSOLE
start /MIN mintty.exe -i /Cygwin-Terminal.ico "%~dp0start-isabelle.bash"
:: REGULAR WINDOWS CONSOLE
::bash --login -i "%~dp0start-isabelle.bash"
FILE: start-isabelle.bash
#!/usr/bin/env bash
#
isabelle jedit -l HOL
With 64-bit Java, I can increase the size of the memory that Isabelle uses, by making this change in .isabelle\Isabelle2015\etc\settings:
JEDIT_JAVA_OPTIONS="-Xms1g -Xmx4g -Xss4m"
or
JEDIT_JAVA_OPTIONS="-Xms1024m -Xmx4096m -Xss4m"
With 32-bit Java, when I do that, Isabelle will start but then terminate.