I am using Ubuntu 13.10. Is it possible to debug a windows executable under Linux?
I've tried gdb, but it always throw me this error message.
/bin/bash: line 0: exec: /some.exe: cannot execute: Permission denied
I don't have much experience with this but, I think, what you're looking for is winedbg. Initially, it should allow you to debug Win32 applications in Linux.
I suggest you try the IDA Debugger (cross platform debugger).Hope it helps.
You are trying to execute a program designed to run in a OS, from within another one, which could be using a complete different processor than a x86.
In order for a executable program to be run in a specific OS, these modules or services must exist:
A module that can understand the binary code of the executable program and translate, if needed, into binary code of the host processor.
A service that can intercept any instruction identified as a system call, and emulate its behaviour using host resources
A module that is able to load, parse and prepare a process block to acommodate the new "guest" process
This is just for executing a program. To debug it, you also need a service that can interact with the above mentioned modules/services in order to control execution of that program.
That said, you can probably debug an EXE file using some utility from the Wine project, asumming your Ubuntu is running on a x86 processor. Take a look at it.
http://www.winehq.org/
Also, I recall VirtualBox offers some sort of debugging help for processes running on the guest OS, but I'm not sure about this.
No, it is NOT possible to debug a Windows executable under Linux.
Related
I always used GDB to do kernel debug. Normally I would run the target kernel inside a VM and run GDB from the host machine. Currently I am working on a project where I need to use XEN hypervisor and I am in a situation where I feel the need to debug a DOM-U from DOM-0. After some searching I couldn't find a way to use GDB in this scenario. Is it possible to use GDB to debug a guest VM running in XEN? If not, what other alternatives I could use?
You can create a pipe (for example, /tmp/mydebug.pipe), then have this line in the .conf file for your domU:
serial = 'pipe:/tmp/mydebug.pipe'
Then you can simply use a tool such as WinDBG from another domU. See mkfifo.
Other possibly useful links:
https://xenserver.org/partners/developing-products-for-xenserver/18-sdk-development/135-xs-dev-windbg.html
http://www-archive.xenproject.org/files/xensummit_intel09/xen-debugging.pdf
https://www.slideshare.net/xen_com_mgr/from-printk-to-qemu-xenlinux-kernel-debugging
I need to launch server executables from terminal. They are running through wine (because those executables are for Windows) in the background. If I launch them normally, from Terminal, those work without any problem.
Now I'm trying to make CGI (bash) script and launch servers from website, but script doesn't launch processes. I thought that it has something to do with wine, but no, script doesn't launch any processes at all.
I'm building that system on Ubuntu 12.04.1 LTS, after that scripts would go onto Debian server.
So, the question is: is it even possible to run background process from CGI scripts? If yes, would you please explain how?
A CGI program is like any other program, except that it is supposed to run quickly and to follow the CGI protcol (in particular, regarding to stdout output).
As with any other Linux program, you can (subject to limitations and permissions on your system) run processes, using syscalls like e.g. fork(2), execve(2) and many others.
I suggest to read a good Unix programming book like Advanced Unix Programming abd Advanced Linux Programming. We can't teach all that here in a few minutes.
You could also run processes using the library system(3) and popen(3) functions (of course these functions are implemented using syscalls, inside GNU libc)
Don't forget the stateless property of CGIs; you may consider using FastCGI or SCGI instead.
(A program started thru wine from a CGI might fail, e.g. because it has no X11
server to talk to; For C# programs, consider Mono on Linux).
Another possibility could be to run Windows in some VM, and have your CGI interact with such virtualized Windows programs. Not knowing Windows, I have no idea about the issues of such an approach.
I just a ran simple hello world program in my linux it worked perfectly.when i supposed to ran same file in the hand held device (running on the linux os)i got the error like Cannot execute binary file error.i am completely new to linux.
can anybody help me?
Just because the OS is the same does not mean an executable will run. The binary file is composed of machine instructions the processor can understand. Moving back and forth between processors with the compatible instruction sets will normally work fine, but if they are not compatible the CPU will not be able to understand the instructions.
Most Intel processors use a x86 ISA (instruction set architecture), that your mobile processor is likely not compatible with.
Just a heads up because I had this problem but the b4-bit application for 32-bit OS didnt work for me. If your in linux you probably need a gcc compiler on the backend of terminal that might not be installed. If you dont have this Linux doesnt seem to know how to read the file.
su <user-name>
Then command/file should be executed.
I'm trying to debug an application for an ARM processor from my x86 box. I some followed instructions from someone that came before on getting a development environment setup. I've got a version of gdbserver that has been cross-compiled for the ARM processor and appears to allow me to connect to it via my ARM-aware gdb on my box.
I'm expecting that when the process I've got gdb attached to crashes (from a SIGSEGV or similar) it will break so that I can check out the call stack.
Is that a poor assumption? I'm new to the ARM world and cross-compiling things, is there possibly a good resource to get started on this stuff that I'm missing?
It depends on the target system (the one which uses an ARM processor). Some embedded systems detect invalid memory accesses (e.g. dereferencing NULL) but react with unconditional, uncatchable system termination (I have done development on such a system). What kind of OS is the target system running ?
So i assume that the gdb client is able to connect to gdbserver and you are able to put the break point on the running process right?
If all the above steps are successful then you should put the break point before the instruction which crashes, lets say if you dont know where is it crashing then i would say once the application is crashed, the core will be generated, take that core from the board. Then compile the source code again with debug option using -g option(if binaries are stripped) and do the offline ananlysis of core. something like below
gdb binary-name core_file
Then once you get gdb prompt ,give below commands
gdb thread apply all bt
The above command will give you the complete backtrace of all the threads, remember that binaries should not be stripped and the proper path of all the source code and shared lib should be available.
you can switch between threads using below command on gdb prompt
gdb thread thread_number
If the core file is not getting generated on the board then try below command on board before executing the application
ulimit -c unlimited
I know it is possible to remotely debug code using gdb's server mode and I know it is possible to debug code that has been cross-compiled for another architecture, but is it possible to go a step further and remotely debug Linux applications from OS X using gdbserver?
Certainly, but you need a cross-compiled GDB, compiled for OSX-host and Linux-target. This is not at all uncommon; there should be plenty of GDB documentation to cover this.
It is possible from Windows with Cygwin.
I don't know about OS X.