On Thu, Sep 2, 2010 at 2:24 PM, Dave Martin <dave.mar...@linaro.org> wrote:
> On Thu, Sep 2, 2010 at 5:42 PM, Jon Smirl <jonsm...@gmail.com> wrote:
>> On Thu, Sep 2, 2010 at 4:55 AM, Dave Martin <dave.mar...@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.mar...@linaro.org> wrote:
>>>> 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.
>>
>> 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 <m...@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
>
--
Jon Smirl
jonsm...@gmail.com
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
