On Thu, Sep 2, 2010 at 9:31 AM, Ramana Radhakrishnan <ramana.radhakrish...@arm.com> wrote: > >> >> > arm-linux-gnueabi-gcc -g -DDEBUG -Os -fno-strict-aliasing >> > -fno-common -ffixed-r8 -ffunction-sections -msoft-float -Wcast-align >> > -Wall -D__KERNEL__ -DTEXT_BASE= -fno-builtin -ffreestanding -isystem >> > /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include -pipe -march=armv4t >> > -mlong-calls -mtune=arm7tdmi-s -DCONFIG_ARM -D__ARM__ >> > -mthumb-interwork -Wall -Wstrict-prototypes -Wcast-align -Wextra >> > -Werror -Iobj_redbee-econotag_board -I../board -DBOARD=redbee-econotag >> > -I../lib/include -I../src -I. -mthumb -mcallee-super-interworking -MMD >> > -c -o obj_redbee-econotag_board/sleep.o sleep.c >> > sleep.c:1:0: error: AAPCS does not support -mcallee-super-interworking >> >> This sounds like a missing implementation rather than just a toolchain >> flag; or perhaps it's not needed at all with AAPCS? > > -mcallee-super-interworking is ancient and need not be used with AAPCS > toolchains. The linker will deal with interworking issues on AAPCS > toolchains by inserting stubs at appropriate locations and arranging for > correct control and state transfer at the required interfaces.
Note that this may only work if the calls to/from the ROM are via linker-visible interfaces. This means that no magic interworking would happen for things like calling magic addresses, or for callback pointers passed into the ROM. This is because the the tools have no way to know whether the target symbols for call/return are interworking or not in these cases. There are some ways around this--- but it's probably best not to get into that unless it's really needed. Cheers ---Dave > > cheers > Ramana > > > > > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
