4

I have an executable that loads a shared library with dlmopen.

Here is the main.cpp:

int main(int argc, char* argv[]) {
    void* h=dlmopen(LM_ID_NEWLM,"libA.so", RTLD_LOCAL | RTLD_NOW);

    if(h != 0) {
        void (*pPrint)() = (void (*)())dlsym(h, "printA");

        if (pPrint != 0)
            pPrint();
        else
            std::cerr << "Did not find function\n";
    } else {
        std::cerr << "Cannot load shared library\n";
        return 100;
    }

    return 0;
}

And here is A.cpp producing the library:

extern "C" void printA() {
    std::cout << "Hello world!\n";
    return;
}

I compiled this code with g++ 6.3.1. If you try to follow the execution of that code with GDB (I tried with 8.1.0) or DBX, you will notice that you cannot dive into printA(). Researching the web for ways of debugging this piece of code, I found comments here and there that this is expected. It seems some people did some work some time ago (around 2011) to get this to work, but this is not obvious to me how far they went.

Apart from print statements, which is not really an option on my real case, does anyone see a debugging strategy I could follow?

Student
  • 805
  • 1
  • 8
  • 11
Stephane
  • 41
  • 1
  • While debugging, use `dlopen` instead of `dlmopen`. (You could use a command-line argument or an environment variable for this.) – Lorinczy Zsigmond Jul 30 '18 at 13:40
  • @LorinczyZsigmond this would work on the trivial case here, but not on my real world problem, as the executable and the library are linking against common shared libraries in different (incompatible) versions – Stephane Jul 30 '18 at 14:23
  • 2
    The `dlmopen` support in gdb was indeed never finished, primarily because we couldn't find anybody actually using `dlmopen` at the time. My belief is that it requires a glibc change and some gdb changes to work. In the meantime I suppose printf debugging is about all that's available. – Tom Tromey Jul 30 '18 at 15:30

0 Answers0