This message is really off topic for this list, please direct any follow-ups to gcc-help@xxxxxxxxxxxx On Wed, 2009-01-21 at 19:53 +1100, Zoltán Kócsi wrote: > I have a question with regards to ARM interworking. The target is > ARM7TDMI-S, embedded system with no OS. The compiler is arm-elf-gcc, > 4.3.1 with binutils maybe 3 months old. Unless you are working on legacy code (and it doesn't sound like it), you should be using the arm-eabi configuration now, rather than arm-elf. > It seems that when interworking is enabled then when a piece of THUMB > code calls an other piece of THUMB code in a separate file, it calls > a linker-generated entry point that switches the CPU to ARM mode, then > a jump is executed to an ARM prologue inserted in front of the > target THUMB function that switches the CPU back into THUMB mode. That > is, instead of a simple call, a call, a jump and two mode switches are > executed. > No, this shouldn't be happening unless a) you are doing something wrong; b) the options you are supplying to the compiler/linker are suggesting some sort of stubs are necessary. Can you provide precise details of what you are doing. A testcase would be ideal. > I also tried the -mcallee-super-interworking flag, which generates a > short ARM to THUMB switching code in front of a THUMB function, but the > final result does not seem to use the .real_entry_ofFUNCTIONNAME entry > point. Rather, it goes through the same switch back and forth routine. > I would recommend NOT using that option. It's provided only for specific legacy cases where existing code has been built without interworking. There are cases which simply cannot be handled by the methods it uses. R.
