> [snip] >> This is to fix various file not found errors. I am not sure whether it >> is >> 'right' fix. > > No, definitely it's definitely not right. It's strange that you need > those changes, since the Linux RTL Makefile is used daily. Did you > need those changes even to compile it for i386? > No, It is only needed for mipsel. Without this, /home/foxsen/fpc/compiler/ppcrossmipsel -Pmipsel -XPmipsel-linux- -Xr -Fi../inc -Fi../mipsel -Fi../unix -Fimipsel -FE. -FU../../rtl/units/mipsel-linux -g -Xs- -dmipsel ../objpas/math.pp .... unix.pp(498,15) Warning: Symbol "SelectText" is deprecated unix.pp(1070,32) Warning: Symbol "Domain" is not portable Assembling unix sysutils.pp(41,2) Fatal: Can't open include file "sysutilh.inc" Fatal: Compilation aborted make[3]: *** [math.ppu] 错误 1 make[3]:正在离开目录 `/home/foxsen/fpc/rtl/linux' make[2]: *** [linux_all] 错误 2 make[2]:正在离开目录 `/home/foxsen/fpc/rtl' make[1]: *** [rtl] 错误 2 make[1]:正在离开目录 `/home/foxsen/fpc/compiler' make: *** [cycle] 错误 2
sysutilh.inc is in rtl/objpas/sysutils, the cross compiler cannot find it out with the default command line. While for i386 version, when compiling math.pp, needed ppu is already there, compiler won't goto compile system.pp/sysutils.pp etc. thus no error. So it should be a real bug. But where to add the necessary paths can be discussed. >> commands: >> cd rtl/linux; >> patch Makefile.fpc; fpcmake -Ti386-linux,mipsel-linux > > It's better to use -Tall (since there are more Linux targets than just > i386 and mipsel). Yes, I just wanted to make the Makefile short to easy finding something:) Now I am familiar enough to deal with -Tall:) >> >> I know it is related to mips branch offset overflow. > > A similar issue exists on PowerPC: conditional branches are limited to > 16 bit offsets, while unconditional branches can reach up to 26 bits > or so. As far as I can see, it's similar on MIPS (the B* opcodes > versus the J opcode). If so, you may be able to create a MIPS version > of the fixup_jmps procedure in compiler/ppcgen/aasmcpu.pas and add it > to compiler/mips/aasmcpu.pas (it's called from psub.pas, you'll have > to modify the ifdef there to also activate it for MIPS and MIPSEL). Thanks. I've noticed the fixup_jmps. But it seems to deal with branch offset overlow INSIDE a procedure? Chances of this is very few. > > The actual errors you get are strange though. We never insert > conditional branches from one routine to another (in the above case: > from SYSUTILS_$$_finalize, or more likely from interface wrappers > following that symbol, to various other routines). Looking at the code > for tcgcpu.g_intf_wrapper in compiler/mips/cgcpu.pas, the code for > interface wrappers uses the "B" as opposed to the "J" instruction to > branch to the interface wrappers. Maybe that's a copy/paste error from > another platform. I'm not sure what "B" means though, I don't see it > listed at http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html B refers to various branch instructions which are limited to 16 bit offset. There is mips instruction call 'B', only branches like bne/beq. > > Anyway, I guess this patch will solve the above error: Yes, you're right! Now I've got a native version of fpc mipsel. Thank you so much. Now at least we have a very good start. I've a quick look over current mips code, it seems not strong enough. For example, the inverse_cond seems wrong, the setting of first_int_imreg/mavarregs/maxfpuvarregs etc. is hard to understand... I'll read more and come back later. > > Index: compiler/mips/cgcpu.pas > =================================================================== > --- compiler/mips/cgcpu.pas (revision 21359) > +++ compiler/mips/cgcpu.pas (working copy) > @@ -1722,7 +1722,7 @@ > op_onr24methodaddr; > end > else > - > list.concat(taicpu.op_sym(A_B,current_asmdata.RefAsmSymbol(procdef.mangledname))); > + > list.concat(taicpu.op_sym(A_J,current_asmdata.RefAsmSymbol(procdef.mangledname))); > { Delay slot } > list.Concat(TAiCpu.Op_none(A_NOP)); > >> After some >> research,I've found that ppc code support -fPIC. > > PIC normally won't help with branch offset overflows. > >> But when I try to enable >> it,the other issue appears: > > Yes, PIC requires cpu-specific support. It shouldn't be necessary to > get an initial port up and running though. > > > Jonas > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel