Re: ARM FDPIC port

Hi Christophe,

I'll answer to the best of my knowledge.  Hopefully, other people will 
jump to correct me where I'm wrong.

On 2018-12-06 09:47, Christophe Lyon wrote:
> Hi!
> 
> 
> 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.

Thanks for the summary.

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

Good idea!

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

The code is compiled when people use --enable-targets=all, so we know it 
builds.  But there hasn't been frv-specific contributions or fixes for a 
while, the only changes to frv-tdep.c, frv-tdep.h and solib-frv.c in the 
last ~10 years were GDB-wide refactorings.  So you can expect some bit 
rot.

> 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?

It's hard to tell you what to do, since I don't know either frv nor arm 
fdpic.  But from what I understand, I think it would make sense to first 
have a patch that extracts the shared bits of solib-frv.c to 
solib-fdpic.c.  A subsequent patch would add the bits to make the ARM 
port use solib-fdpic.c.

> 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?

No idea.  There is no "bare-metal" frv build configuration, which means 
frv-tdep.o and frv-linux-tdep.o are always included in an frv build:

225 frv-*-*)
226         # Target: Fujitsu FRV processor
227         gdb_target_obs="frv-tdep.o frv-linux-tdep.o linux-tdep.o 
solib-frv.o"
228         gdb_sim=../sim/frv/libsim.a
229         ;;

It's possible that some things were added to the wrong file, without 
considering whether they are frv-specific or frv-linux-specific.

> 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 ?

Good question.  I don't see any downside to doing that.  Otherwise, it 
should always be possible to add support for it in any GDB build by 
specifying --enable-targets=arm-uclinuxfdpiceabi.

> Is it possible/desirable to link solib-svr4.c and solib-fdpic.c into
> the GDB executable at the same time?

Yes, with an --enable-targets=all build, all solib-*.c files are built 
and linked.

> For reference, our old branch is available on github:
> https://github.com/mickael-guene/gdb/commits/gdb-7.5.1-fdpic-m

Simon