Re: arm thumb interworking funkyness.

[Khem Raj <kraj at mvista dot com>]

On Apr 23, 2007, at 6:43 PM, Duane Ellis wrote:

> duane> I'm trying to write a small bit of ARM asm, that is callable  
> from mixed code.
>
> raj> Can you make sure that you are looking at the right location  
> in the disassembly.
> raj> From what you provided it works correctly.
> raj> You might have to give more information if you still are stuck.
>
> I've been trying to, and now I've modified the code enough that I  
> can no longer
> produce the original error! Sigh... Oh what fun.
>
> However - I can now cause binutils to die with asserts!

Try your example with latest binutils from trunk. If this still  
happens then file a bug with this example.

> See below.
>
> -Duane.
>
> ========================
> arm-elf-gcc -DFAIL1 -DFAIL2 -mthumb -mthumb-interwork - 
> nostartfiles  -o test.arm-elf  foo.c irqfunc.S
> foo.c: In function 'main':
> foo.c:9: warning: return type of 'main' is not 'int'
> /bigdisk/arm/tools2/install/i686/lib/gcc/arm-elf/4.1.2/../../../../ 
> arm-elf/bin/ld: BFD 2.17 assertion fail elf32-arm.c:2686
> /bigdisk/arm/tools2/install/i686/lib/gcc/arm-elf/4.1.2/../../../../ 
> arm-elf/bin/ld: BFD 2.17 assertion fail elf32-arm.c:2733
> ========================
>
> Perhaps, what I have done is moved the problem enough that the  
> BFD_ASSERT() is catching.
>
> I believe (a hunch) but cannot prove that *THIS* problem is   
> related to a *DIFFERENT* bug I filed over the weekend.
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=4408
>
>
> **OR** - perhaps One is not allowed to do what I am doing.... and I  
> must wrap it all up in nasty macros.
>
> hence, the thrust of my original question. What is the _proper_ and  
> _officially_sanctioned_ way of doing this with gcc/gas/gnu-ld?
>
> ======================================
>
> The code that demonstrates this *NEW* issue is _inline_ below.
>
> It is contrived - and purposely made small to make the linker link  
> without a ton of other files.
>
> That is to say: The code is valid, I see no reason for it not to  
> link properly.
> However, it does nothing meaningful other then to demonstrate the  
> problem
>
> I'm just trying to reduce my original problem to a small concise  
> little example.
>
> ==========================
>
> There are 3 files
>
>     irqfunc.S -- Contains a small bit of ARM assembly
>
>          The purpose of what I'm trying to do is *NOT* use linker
>          generated arm/thumb veneers, but instead, create my own.
>
>    foo.c        -- Contains a small bit of C, that calls the ARM  
> assembly.
>    Makefile  - That compiles the above two things and links them.
>
> Examine the makefile,  and try permuations of "-DFAIL1" and "- 
> DFAIL2" (removing
> both defines cause the compiler to insert its own veneer, where it  
> has no problem)
>
> === MAKEFILE ====
>
> CFLAGS=-DFAIL1 -DFAIL2
>
> test.arm-elf: foo.c irqfunc.S
>    arm-elf-gcc ${CFLAGS} -mthumb -mthumb-interwork -nostartfiles  - 
> o $@  foo.c irqfunc.S
>
> test.dis: test.arm-elf
>    arm-elf-objdump -D test.arm-elf > $@
>
> clean:
>    rm -f test.arm-elf
>    rm -f test.dis
>
> remake: clean test.dis
>
> === irqfunc.S ====
>
>    .text
>
> #if defined(FAIL1)
>    nop
> #endif
>   #if defined(FAIL2)
>    .code 16
>    .global    __MyFunction_from_thumb
>    .thumb_func
>    .type __MyFunction_from_thumb, function
> __MyFunction_from_thumb:
>    bx    pc
>    nop
>    .size __MyFunction_from_thumb,(.-__MyFunction_from_thumb)
> #endif
>    .code 32
>    .global    MyFunction
>    .type MyFunction,function
> MyFunction:
>    mrs    r0,cpsr
>    bx    lr
>    .size    MyFunction, (.-MyFunction)
>
> === foo.c  ====
>
>
> int _start(void)
> {
>  /* this is fake */
> }
>
> void
> main( void )
> {
>  MyFunction();
> }




Khem Raj <kraj@mvista.com>
MontaVista Software Inc.



--
For unsubscribe information see http://sourceware.org/lists.html#faq