I have an executable provided as is. The creators have compiled it with minimal dependencies and no symbols. When I load it in gdb it sais:
...(no debugging symbols found)...done.
I would like to do step-by-step debugging in the assembler code with the optional exit point in case the execution does leave the shared executable. The reason I need this is because I have an executable which segfaults and I have no other means of tackling the problem.
I have created a minimalist example (simple.c++):
#include <stdlib.h>
#include <iostream>
int main () {
std::cout << "Hello World!" << std::endl;
return EXIT_SUCCESS;
}
and compile it with:
g++ -static -O3 simple.c++ -o simple
strip simple
Thank You in Advance.
I would like to do step-by-step debugging in the assembler code
What is stopping you from doing just that?
readelf -h a.out will tell you what address the start is at. Set a breakpoint there and continue with stepi or nexti.
This will actually take a really long time, so a more efficient approach might be go backwards from the crash point, rather than forward from start. That is, run the binary until crash point, then figure out how you got there, set a breakpoint earlier, and re-run. Reverse debugging may also help.
Related
If I define a symbol address when linking a program on Ubuntu 16.10, this doesn't seem to produce the correct address when running the program. For example taking the following program
#include <stdio.h>
extern int mem_;
int main()
{
printf("%p\n", &mem_);
}
and compiling with
gcc example.c -o example -Xlinker --defsym=mem_=0x80
then running the program prints 0x80 on older Ubuntu systems, but a random number on Ubuntu 16.10. The 0x80 symbol seems to go into the executable, as shown by the nm program, however.
Any ideas what's causing this? I'm suspecting a security feature.
Under the GCC section of the ChangeLog (found here: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes)
"We have modified GCC to by-default compile programs with position independent executable support, on the amd64 and ppc64el architectures, to improve the security benefits provided by Address Space Layout Randomization."
To disable this option, simply add -no-pie to GCC's flags.
I'm running Linux on spike as described at: http://riscv.org/download.html#tab_linux. With busybox I have a powerful tool to run several usefull tools. The next thing I am trying to achieve, is to run my own program on riscv/Linux. Therefore I wrote a little program:
#include <stdio.h>
int main(void) {
printf("Hello world!\n");
return 0; }
compiled it with riscv64-unknown-linux-gnu-gcc and added the binary to the root.img of riscv/Linux. The Problem I now have is, that if I want to execute the program under riscv/Linux threw ./hello, the following message appears on my shell:
-/bin/ash: ./hello: not found
My Question now is (1) what am I doing wrong and (2) is there at all a possibility to run a program on riscv/Linux the way I am trying accomplish it?
My guess is that your hello program is dynamically linked to a runtime library that is missing from your root file system.
You can use 'ldd' to find which dynamic libraries your application is linked with and make sure all of them are present on the root file system or simply compile the hello program statically.
I have searched through forums here, but nothing helped to the end in my case.
I'm trying to write and compile some C++ multithreading code in Code::Blocks 13.12, for now the only code I have is:
#include <iostream>
#include <thread>
void cpp11()
{
std::cout<<"C++11 MULTITHREADING\n";
}
int main()
{
std::thread t(cpp11);
t.join();
}
Initially I could not compile and run that code (both in Code::Blocks and Terminal) because I was getting an error:
Terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not
permitted.
I found that I'm able to compile and run that code calling g++ in the Terminal like that:
g++ -std=c++11 -pthread main.cpp -o Program
but I cannot set the same in Code::Blocks.
I went to Project -> Build options, in the Compiler settings tab I selected Have g++ follow the C++11 ISO C++ language standard [-std=c++11].
In the Compiler settings -> Other options I typed -pthread.
In Linker settings -> Other linker options I typed -pthread.
It does not work, after I build and run my project in Code::Blocks I get the same error message.
Thank you for any help!
Follow instructions for this question
How do I link to a library with Code::Blocks?
in the last step, when Add library dialog pops up type pthread.
UPDATE
Again go to build options > Compiler settings . click on other options and type -pthread
I cross-compiled a Helloworld executable for ARM. It worked well on my friend's development board, but failed with a " segmentation fault " on my board. The two boards are slightly different in both hardware and software.
My question is, how can I debug in my board? Is it relatively easy to debug such a simple program? Does it indicate that there's nothing wrong with the executable and the problem most probably lies in the filesystem of my board?
Below is the code:
#include <QApplication>
#include <QPushButton>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton hello("Hello world");
hello.resize(100, 30);
hello.show();
return app.exec();
}
And the executable is generated by the following commands:
qmake -project
qmake
make
most probably gdb is ported to be run on ARM target but in case lack of that or for easy debugging, you should use gdb remote debugging.
http://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html#Remote-Debugging
Gdbserver is the application should be run on target. the following is demonstration howto use it. (copied from wikipedia)
Target settings:
remote$ gdbserver :2345 hello_world
Process hello_world created; pid = 2509
Listening on port 2345
Host settings:
local$ gdb -q hello_world
Reading symbols from /home/user/hello_world...done.
(gdb) target remote 192.168.0.11:2345
Remote debugging using 192.168.0.11:2345
0x002f3850 in ?? () from /lib/ld-linux.so.2
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08048414 in main () at hello_world.c:10
10 printf("x[%d] = %g\n", i, x[i]);
(gdb)
So you mentioned after LD_LIBRARY_PATH your issue was resolved. And before setting the LD_LIBRARY_PATH if your application gives error can not find libQt then it means you do not have Qt, but your application is giving this Seg Fault that mean you have library but not the right one so we can say you have multiple installations of Qt on your filesystem.
The one to which you have pointed now is correctly compiled for your current hardware but the other one is not compiled for your hardware causing the Segfault and this installation is in your library search path.
One possible reason of this seg fault can be determined from below.
Following are some CFLAGS which if not set correctly for any particular hardware, the compiled application / library causes Seg faults at run time.
-march
-mtune
-mfpu
So if your binary / library is compiled with say -march=armv5a and you are running it on ARM9 then it will crash like this.
Also note that not all application uses these flags, usually these flags are optimization flags and are used by base system libraries (i.e Qt, Glib, bison, Gtk etc....).
Even if you write a simple C based hello world application and your glibc is not compiled for your hardware you will get the Seg fault.
Answer from Author:
What caused this "segmentation fault" is exactly the software difference of the board. Specifically, the environmenat variable LD_LIBRARY_PATH was predefined in the failed board. And I added my path by the command
export LD_LIBRARY_PATH=$LD_LIBRARAY_PATH:/my/qt/path
Thus the predefined paths caused the problem ( still don't know in what way ).
If I change the command to
export LD_LIBRARY_PATH=/my/qt/path
the executable works.
As a general rule you shouldn't create objects derived from QObject on the stack as the QMetaObject system manages the life-time of objects with a parent-child relationship, and will therefore risk free()ing memory on the stack.
I have a simple assembly program with the following makefile:
all : calc
calc : calc.o
gcc -m32 -g -o calc calc.o
calc.o : calc.s
nasm -f elf -g -F stabs calc.s
I try to debug it using gdb but it always says:
Single stepping until exit from function asc2int, which has no line number information.
I tried many solutions to the problem, including -F dwarf but none of them works. Can you please help me resolve this issue?
I don't see any problems with your makefile.
Quick google search gives following nasm. The documentation example shows you need to disassemble to look through the code, but its kind of weird, as already assembly code is being debugged why would the debugger ask to disassemble it further. However the disassembled code is inline with assembly source file.
Form what you have mentioned it seems you are able to debug. use nexti in case if you are using next instruction to step through. You can you disassemble command to every time see where the execution control lies. Or if you want it automated you can save following as a script. asm_next becomes the new instruction for you step in through the code.
set language asm
set disassembly-flavor intel
define asm_next
nexti
disassemble
end
Run it using the command
gdb -x <script> calc
P.S. for larger programs you might need to ad -O0 flag to get correlation between debugger disassembled code and your assembly code in .s file.