Christophe Lyon
Thu Dec 6 14:47:00 GMT 2018


Some of you may have noticed that I am in the process of upstreaming the ARM-FDPIC toolchain we developed a few years ago.

As a reminder, FDPIC is used to run Linux on MMU-less systems.

A major difference with the existing Linux port is that functions are referred to by a function descriptor (FD) consisting of 2 words: the function address, and the address of the GOT associated with the shared object executing the function.

So far, QEMU, binutils and uclibc-ng patches have been merged, and while I'm waiting for review of the GCC patches, I thought I could give a look at the GDB patches :-)

GDB supports FDPIC on FRV, but I'm not sure how well maintained it is?

Since I haven't contributed to GDB for several years, I'd like some guidance on how to proceed to update our patches. The main change is the addition of solib-fdpic.c, which has a lot of similarities with solib-frv.c. I'm wondering whether I should first remove FRV dependencies in solib-frv.c, probably rename it into solib-fdpic.c and make the ARM port use it with the appropriate hooks, or if I should rather add our new solib-fdpic.c file after updating it to the new C++ coding style GDB has adopted since we worked on it?
I've noticed that solib-frv.c has some dependencies in frv-tdep.c, which I don't understand why they aren't in frv-linux-tdep.c instead?

Another thing I'm considering is that since the Linux kernel is able to load FDPIC binaries (if configured to do so) even on MMU-enabled systems, should I make arm-linux-gnueabi-gdb able to handle FDPIC binaries, or restrict that possibility to arm-uclinuxfdpiceabi-gdb ? Is it possible/desirable to link solib-svr4.c and solib-fdpic.c into the GDB executable at the same time?

For reference, our old branch is available on github:



More information about the Gdb mailing list