I'm not very good at working with embedded systems. But the moment got into some vicious circle. Collected python 2.7 (under linux) for the controller (judging by what
uname -a produces, it has an i486 processor architecture). Python starts up, runs. But when importing libraries that require dynamic libraries for example:
requires _random.so etc. a
segmentation fault appears. By experience, I realized that the problem with calling the
dlopen function (I wrote a simple helloworld), which falls into the
segmentation fault exactly when
... cout << "Opening libmyf.so...\n"; void* handle = dlopen("./libmyf.so", RTLD_LAZY); ...
Next, I try to install gdb in order to understand in general where it falls. But here comes the main problem: how to build gdb. There are a lot of manuals on the Internet, I have already tried almost everything. Either gdb is not built, or it is built, launched on the controller, but itself falls into a segmentation fault when debugging starts. Questions:
- If gdb is started, help, for example, works, and then it issues a "segmentation fault" itself when debugging starts. This may be due to the fact that he is somehow crookedly assembled by me or not?
- How to properly compile gdb for linux. Which flags should I indicate, which ones shouldn't? Who in general can advise what in my situation (except to kill obsten :))?
Options for further action:
- Make an emulator (virtual machine, chroot) with this environment on a normal computer by copying the kernel and the system from the embedded system into it. If everything works on the emulator, then the problem may be in the processor instructions;
- Strace is easier to use. To dynamic libraries, however, this has an indirect relationship;
- Use valgrind. If it is too heavy, then use item "1.", increasing the amount of memory in the emulator; Valgrind also has a mode for interacting with gdb.
LD_DEBUG=symbolsetc. With these environment variables, the dynamic loader should print more messages.