CS-476: Loader failure : offset too big

Hello,

For the miniproject I cross-compiled a big library to NIOS II. Everything compiles fine separately but when trying to link the final executable I get the following error:

miniproject_cpu_0_bsp/HAL/src/alt_instruction_exception_entry.c:95: warning: Unable to reach (null) (at 0x040b760c) from the global pointer (at 0x040a805c) because the offset (62896) is out of the allowed range, -32678 to 32767.

the line is

if(alt_instruction_exception_handler) {

alt_instruction_exception_handler is a global variable declared in the same file. So it should go in the data or bss section.

I have multiple ideas but not sure which to follow and how.

1) The range matches exactly 16 bits, so I assume it's an immediate instruction. Using nios2-elf-objdump -D -l it tells me that a call instruction is at line 95, which makes sense for the immediate part but why should a call be created at this line? The optimization flag is -O0 so optimization shouldn't be an issue. Anyway, I thought I could write inline assembly but am not sure how to get &alt_instruction_exception_handler

However, this would be a fix for a single instance, the fact that some parts from the data section are too far away from some part of the text section remains. And having to write multiple times inline assembly to avoid this seems bothersome. This leads me to the second idea

2) Fragment the sections, so that I have in memory: .text.bsp -> .data.bsp -> .text.lib -> .data.lib -> .text.app -> .data.app. I already wrote some linker scripts for other projects but cannot find anything about such an interleaving.

What do you think of both options and could you point me to resources on the most appropriate. Or, of course, if I missed the point completely and there is a simple fix.

Thanks in advance,

Axel

Re: Loader failure : offset too big

par Sahand Kashani, vendredi, 4 juin 2021, 10:10

Hi,

Unfortunately the Nios CPU uses signed 16-bit offsets in its ISA for immediate-type instructions, and it seems your external library has caused the BSP's exception handling code to be out of range from some location (though I cannot tell what that location is from your code)/

As you said, manually patching the branches would not be a global solution. I read through the GCC options for the Nios processor and there seems to be a way to disable the generation of gp-relative addresses. Perhaps you can try that first before manually modifying the linker script (through the BSP's interface).

https://gcc.gnu.org/onlinedocs/gcc/Nios-II-Options.html

The -mgpopt='none' option looks like it could solve the issue. I have never tried it out though, so I can't say for sure if it would solve the problem, but it could be worth a shot.

Re: Loader failure : offset too big

par Axel Marmet, vendredi, 4 juin 2021, 11:16

Thanks for the answer, *

the option does seem promising but when I use it I still see gp accesses in the objdump. Is it possible that the optimization flags are not used for the .exceptions section?

Re: Loader failure : offset too big

par Axel Marmet, vendredi, 4 juin 2021, 11:30

Fixed it in the end :)

I'm not exactly sure why but when I wrote it in the makefile myself it didn't work but after looking at the bsp settings I saw an option for that. And when I used it, it worked. It seems to write the same exact line as what I did though. Maybe there is some annoying metadata messing things up if it's added manually?

Re: Loader failure : offset too big

par Sahand Kashani, vendredi, 4 juin 2021, 12:55

I think modifying the makefiles by hand rarely works as it's unclear when eclipse automatically overwrites them. But glad to hear the BSP settings page fixed it!