[ un-breaking Loic email address in CC so people reply to the right place--- not sure what happened there ]
On Thu, Sep 2, 2010 at 9:53 AM, Dave Martin dave.martin@linaro.org wrote:
On Thu, Sep 2, 2010 at 9:31 AM, Ramana Radhakrishnan ramana.radhakrishnan@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