Segmentation fault when calling dlopen and starting debug using gdb

Question:

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:

import random

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 dlopen called.

...
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:

  1. 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?
  2. 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 :))?

Answer:

Options for further action:

  1. 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;
  2. Strace is easier to use. To dynamic libraries, however, this has an indirect relationship;
  3. 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.
  4. Use LD_DEBUG=libs LD_DEBUG=symbols etc. With these environment variables, the dynamic loader should print more messages.
Scroll to Top