compiling application with -elf2flt suffered errors "unexpected reloc type"

[Altera_Forum]

Hi, 

I suffered errors "ERR:unexpected reloc type R_NIOS2_UJMP" and "ERR:unexpected reloc type R_NIOS2_CJMP", total 480 these errors, while compiling my application runing "nios2-linux-gcc -g -o APP_DEMO -lc -lm -lpthread ${OBJ} -elf2flt". and it's ok compiling without -elf2flt . I doubt the tool nios2-linux-elf2flt may be with some bugs. I find the source code(elf2flt.c) of the tool in the directory nios-linux/elf2flt/. it just prints out errors when encounters some relocation types, such as R_NIOS2_UJMP,R_NIOS2_CJMP and so on.  Is there anyone suffered this problem? I just try to fix thus unsupported relocation types ,modifying the source elf2flt.c, and I need helps.  Any experience or infomation or tips are appreciated, thanks!  Attachment：my makefile and make log  

[Altera_Forum]

I, too, have had a similar issue recently. I have yet to determine the cause. It seems, in my particular code, that once a certain "threshold" is crossed, whether from nested "ifs", preprocessor directives, etc., that elf2flt cannot complete successfully. 

 I see varying numbers of "Err: unexpected reloc type R_NIOS2_CJMP(19)" and "Err: unexpected reloc type R_NIOS2_UJMP(18)" errors based on the compiler optimization level that I set. I assume this is because elf2flt is maybe processing post-compiled code (binary)? I am unfamiliar with the inner workings of elf2flt, and even its purpose for that matter, so I may be stating the obvious.  Does anyone have any insight into solving this problem? It may require me to include more information on my build, but I am unsure at this point what information might be relevant.  Thanks, Jason

[Altera_Forum]

I have been working this afternoon on solving this issue. It is difficult to proceed when things like this hold you up! 

 It is not a solution, but just a theory based on empirical evidence through fiddling with my own code. Please note that I have done very little investigating into how elf2flt works, so consider this when reading my theory. I would LOVE to have any of my errors corrected by someone familiar with the topic.  It seems that there is some sort of generic limitation with code size or stack size or something when executing elf2flt. I have adjusted my stack size parameter being passed to elf2flt from the default 4KB to 64Kb to 256Kb to 512Kb to 2MB. None of these adjustments made the problem go away. The one thing that did work for me, however, is converting some static array variables (put on the stack) to dynamically allocated arrays (heap space). This immediately solved the problem. The only "downside" is the housekeeping involved with the dynamically allocated variables... no big deal.  This has all lead me to believe that there is, in fact, some code size/variable size/stack size boundary that CANNOT be exceeded regardless of what the stack size parameter is set to.  Again, please, if anyone knows what is really going on... I am more than interested in hearing a competent answer.  Regards, Jason

[Altera_Forum]

is converting some static array variables (put on the stack) to dynamically allocated arrays (heap space). 

     can you give me an example??

[Altera_Forum]

Static variables on the stack? Really? I don't have the compiler in front of me right now, but every other compiler I've worked with would not put static variables on the stack, because there is no need. They're static, so they go into memory with the global variables. 

 One thing I do know. a lot of times, the error messages are absolutely no help at all and will actually tell you to look for a problems far, far away from where the problem actually is.  However, I have seen a similar type of error from another cause. Seems that many memory access are done relative to the gp register, something like:  (load register) r2,XXXX(gp) ; I forget the exact mnemonics, but it's something like this   This means: use the value in the gp register, offset it by the 16-bit immediate value XXXX and put the value at that memory location in r2.  The problem is if it is more than +-32K away, it fails with a whole string of error messages, most of them being completely negatively helpful, but I think I remember things like 'reloc' errors, and similar.  It's been awhile since I saw this, but I think it came from having overlapping addresses assigned for memory in SOPC. I used the auto assign addresses, regenerated the processor, generated a new BSP, and recompiled. The compiler was much happier after that.  Don't know if it will help, but thought I'd offer.

[Altera_Forum]

All global variables are accessed via GP, as the NIOS instruction set does not have an instruction that uses a (32 bit) direct address (obviously: the instruction code is just 32 bits :) ).  

 Only thread vars (__thread keyword) are accessed via a different register.   The load/store instructions only provide a signed 16 bit "offset" so you are right that only +/32 K is possible. (The Linker can "reloc" ate them correctly to be GP-relative.)  I suppose the linker and the OS will place GP at the beginning of the global variables area and thus in fact only some 32K global variables are possible in a program, unless the compiler provides a method to access them with slower code than usual (in a dedicated "far" region). I don't know whether the compiler/linker can do this, but obviously it needs to be defined in the make/linker scripts.   Supposedly same holds for consts that I think are just global variables initialized when loading the program.  -Michael

[Altera_Forum]

My mistake... I did not mean "static" variables, I should instead have said "automatic" variables. I believe that makes my previous statement accurate.

[Altera_Forum]

AFAIK, global and static (and non-local const) are all accessed via GP. 

 If you do local (stack) variables, same are accessed via SP or FP in the same manner. Thus constructs > 32 K will be problematic, as well.  -Michael