The toolchain isn't built with -mcallee-super-interworking enabled. Could we get that turned on? It is needed to make calls to thumb code in ROM.
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
On Thu, Sep 02, 2010, Jon Smirl wrote:
The toolchain isn't built with -mcallee-super-interworking enabled. Could we get that turned on? It is needed to make calls to thumb code in ROM.
Sounds like an extra header on all functions for which we'd pay a size price, while the current maverick armel binaries are all Thumb. Isn't this specific to your use case?
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?
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.
cheers Ramana
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
[ 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
On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin dave.martin@linaro.org wrote:
[ 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.
The Freescale mc13224 contains an armv4t and a ROM that implements a bunch of radio support in thumb code. Freescale has licensed this code from somebody and can't release it GPL. The link libraries supporting it are also not GPL.
Freescale's solution to this is to provide us with a human readable link map for the ROM. With the link map we have the entry points and can read the documentation on how they work.
So what's the best way to access this ROM? Mar, are there other issues?
We'd really like to see a standardized cross ARM toolchain. Right now we are all building our own with various compatibility issues. What about prebuilt newlib too?
I'm in the process of writing Linux kernel support for talking to these 802.15.4 radios.
On Thu, Sep 2, 2010 at 5:42 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin dave.martin@linaro.org wrote:
[ 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.
The Freescale mc13224 contains an armv4t and a ROM that implements a bunch of radio support in thumb code. Freescale has licensed this code from somebody and can't release it GPL. The link libraries supporting it are also not GPL.
Freescale's solution to this is to provide us with a human readable link map for the ROM. With the link map we have the entry points and can read the documentation on how they work.
If I remember correctly, with the newer AAPCS ABI, non-interworking code is not supported directly: to conform to the ABI, code _must_ interwork.
You may find that using a legacy ABI such as -mabi=atpcs will allow you to use the super-interworking options, but since support for this may eventually disappear this might not be the best long-term approach.
Otherwise, I guess the solution depends on what types of transition occur between the ROM and your code.
Since you are building your code in Thumb, and the code you are calling in the ROM is also Thumb, you might not need interworking at all.
If you are passing callbacks to the ROM which the ROM expects to call as ARM code, you have the option of writing some assembler stubs in ARM for getting from the ROM to your callbacks, and passing the stubs' addresses to the ROM instead of the real function entry points. This is effectively what -mcallee-super-interworking does if I understand the documentation correctly. Alternatively, simply build your callback functions as ARM: since you are building your code with interworking, there should be no problems unless the callback functions call back into the ROM. Returning from a callback to the ROM is probably not a problem, since _your_ functions are built with interworking enabled and will return in the correct way.
For calling the functions in the ROM, doing things like ((void (*)())<address>)() should work fine, though you must remember to set the bottom bit of the address if the target function is Thumb. Defining the symbols in a linker script should also work, and avoids adding any extra code to the image -- the same restriction applies concerning the bottom bit of the address.
Returning correctly from ROM functions back to callers in your code is unlikely to be a problem--- either the ROM code will unconditionally return to Thumb state (OK for you since you are building your code in Thumb anyway) or the ROM code will do correct interworking returns. Depending on how the code in the ROM was generated, there might be a mixture of these two cases.
Do you have any thoughts on this, Ramana? Is there an easier way?
Cheers ---Dave
On Thu, Sep 2, 2010 at 2:24 PM, Dave Martin dave.martin@linaro.org wrote:
On Thu, Sep 2, 2010 at 5:42 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin dave.martin@linaro.org wrote:
[ 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.
The Freescale mc13224 contains an armv4t and a ROM that implements a bunch of radio support in thumb code. Freescale has licensed this code from somebody and can't release it GPL. The link libraries supporting it are also not GPL.
Freescale's solution to this is to provide us with a human readable link map for the ROM. With the link map we have the entry points and can read the documentation on how they work.
If I remember correctly, with the newer AAPCS ABI, non-interworking code is not supported directly: to conform to the ABI, code _must_ interwork.
You may find that using a legacy ABI such as -mabi=atpcs will allow you to use the super-interworking options, but since support for this may eventually disappear this might not be the best long-term approach.
Otherwise, I guess the solution depends on what types of transition occur between the ROM and your code.
Since you are building your code in Thumb, and the code you are calling in the ROM is also Thumb, you might not need interworking at all.
If you are passing callbacks to the ROM which the ROM expects to call as ARM code, you have the option of writing some assembler stubs in ARM for getting from the ROM to your callbacks, and passing the stubs' addresses to the ROM instead of the real function entry points. This is effectively what -mcallee-super-interworking does if I understand the documentation correctly. Alternatively, simply build your callback functions as ARM: since you are building your code with interworking, there should be no problems unless the callback functions call back into the ROM. Returning from a callback to the ROM is probably not a problem, since _your_ functions are built with interworking enabled and will return in the correct way.
For calling the functions in the ROM, doing things like ((void (*)())<address>)() should work fine, though you must remember to set the bottom bit of the address if the target function is Thumb. Defining the symbols in a linker script should also work, and avoids adding any extra code to the image -- the same restriction applies concerning the bottom bit of the address.
Returning correctly from ROM functions back to callers in your code is unlikely to be a problem--- either the ROM code will unconditionally return to Thumb state (OK for you since you are building your code in Thumb anyway) or the ROM code will do correct interworking returns. Depending on how the code in the ROM was generated, there might be a mixture of these two cases.
Do you have any thoughts on this, Ramana? Is there an easier way?
Mar, how are you getting this? Maybe there is a simple solution to calling the ROM thumb code that we haven't discovered yet.
On Thu, Sep 2, 2010 at 3:10 PM, Mariano Alvira mar@redwirellc.com wrote:
Anyway, calle-super might not be necessary --- I might have done that back when I wasn't building everything in THUMB. Now though, without callee-super, and 4.5 I get this a lot:
tests.c: In function ‘print_packet’: tests.c:66:1: error: insn does not satisfy its constraints: (insn 221 23 24 3 tests.c:53 (set (reg/f:SI 6 r6 [171]) (reg/f:SI 13 sp)) 168 {*thumb1_movsi_insn_osize} (nil)) tests.c:66:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions. make: *** [obj_redbee-econotag_board/tests.o] Error 1
I'll try 4.4.
-Mar.
Cheers ---Dave
On Thu, Sep 02, 2010 at 03:30:31PM -0400, Jon Smirl wrote:
Mar, how are you getting this? Maybe there is a simple solution to calling the ROM thumb code that we haven't discovered yet.
Right now I'm thinking that I have callee-super in there as a hold-over from back when I first was starting and built everything as ARM. Now that I'm building things as THUMB it doesn't look like callee-super is necessary.
Now, with 4.4 and 4.5, I'm having the following build problem:
tests.c: In function ‘print_packet’: tests.c:65:1: error: insn does not satisfy its constraints: (insn 215 23 24 3 tests.c:52 (set (reg/f:SI 6 r6 [171]) (reg/f:SI 13 sp)) 168 {*thumb1_movsi_insn_osize} (nil)) tests.c:65:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions.
However, removing the offending code still does not make a simple blink program work. I don't have either of these problems with gcc-4.3-arm-linux-gnueabi from emdebian.org... I imagine it's going to take some deeper work with the debugger to figure out what's going on with 4.4 and 4.5.
-Mar.
On Thu, Sep 02, 2010, Mariano Alvira wrote:
Now, with 4.4 and 4.5, I'm having the following build problem:
[...]
See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions.
Ah that's interesting; which exact compiler are you using? Could you provide a minimal test case we could reproduce this bug with?
On Fri, Sep 03, 2010 at 01:06:03AM +0200, Loïc Minier wrote:
On Thu, Sep 02, 2010, Mariano Alvira wrote:
Now, with 4.4 and 4.5, I'm having the following build problem:
[...]
See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions.
Ah that's interesting; which exact compiler are you using? Could you provide a minimal test case we could reproduce this bug with?
-- Loïc Minier
Loïc,
Thanks, I've made a minimal test case:
#include <stdint.h>
struct packet { uint8_t length; /* does not include FCS checksum */ }; typedef struct packet packet_t;
void bad(volatile packet_t *p) { volatile uint8_t v; uint8_t i;
i = p->length; /* this one builds fine */ v = p->length; /* this one doesn't */
return; }
For the problem to appear you must use -Os -march=armv4t and the volatile assignment. E.g.:
bad: arm-linux-gnueabi-gcc -Os -march=armv4t -c -o tests.o tests.c
ok: arm-linux-gnueabi-gcc -march=armv4t -c -o tests.o tests.c arm-linux-gnueabi-gcc -Os -c -o tests.o tests.c arm-linux-gnueabi-gcc -c -o tests.o tests.c
For this test I'm using 4.5 from here:
deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ./
$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.1-2ubuntu2) 4.5.1
I think you'll have the same result with 4.4 from the same place.
Please let me know if there is any other information I can provide to help!
-Mar.
On Fri, Sep 03, 2010, Mariano Alvira wrote:
For the problem to appear you must use -Os -march=armv4t and the volatile assignment. E.g.:
bad: arm-linux-gnueabi-gcc -Os -march=armv4t -c -o tests.o tests.c
ok: arm-linux-gnueabi-gcc -march=armv4t -c -o tests.o tests.c arm-linux-gnueabi-gcc -Os -c -o tests.o tests.c arm-linux-gnueabi-gcc -c -o tests.o tests.c
Ok; this goes up to -march=armv6, but not -march=armv6t2; it also goes away in ARM mode.
I filed LP #629671 to track this after reproducing with the latest native toolchain which has the latest Linaro released patches.
One thing which would help is reduring the test case from -Os to a set of -f flags; you can find which flags are turned on by -Os with: arm-linux-gnueabi-gcc -c -Q -Os --help=optimizers
On Fri, Sep 03, 2010, Loïc Minier wrote:
I filed LP #629671 to track this after reproducing with the latest native toolchain which has the latest Linaro released patches.
Mariano, mind subscribing to this Launchpad bug since you're the original reporter?
Thanks!
-
Dave Martin -
Jon Smirl -
Loïc Minier -
Mariano Alvira -
Ramana Radhakrishnan