gcc Cortex M4 bug ?

gcc Cortex M4 bug ?

[matti h]

Hi,
Im trying to implement a dynamic linker for M4 mcu's.
But the generated code from gcc seems incorrect to me: im compiling using
arm-none-eabi-gcc: -mcpu=cortex-m4 -mthumb -O2 -ggdb  -Wstrict-prototypes 
-Wunused-parameter -lmylib main.c -o test

Ive created the following program dynamically linked:
----main.c---------
int main()
{
        test();
        return 1;
}

On target I have the function
-------mylib.c-----------
int test()
{
        return 1;
}
arm-none-eabi-gcc -fPIC -mcpu=cortex-m4 -mthumb -O2 -ggdb 
-Wstrict-prototypes -Wunused-parameter -lmylib mylib.c -o mylib.so

------linker script-----
OUTPUT_FORMAT("elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)

PHDRS
{
        headers PT_PHDR PHDRS ;
        interp PT_INTERP ;
        text PT_LOAD FILEHDR PHDRS ;
        data PT_LOAD ;
        got PT_LOAD;
        dynamic PT_DYNAMIC ;
}

SECTIONS
{
        . = SIZEOF_HEADERS;
        .interp : { *(.interp) } :text :interp
        .hash           : { *(.hash) }
        .text : { *(.text) } :text
        .rodata : { *(.rodata) } /* defaults to :text */
        .dynsym         : { *(.dynsym) }
        .dynstr         : { *(.dynstr) }
        .rel.dyn        :
    {
      *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
      *(.rel.got)
    }
        .rela.dyn       :
    {
      *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
      *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
      *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
      *(.rela.got)
    }
        .rel.plt        :
    {
      *(.rel.plt)
    }
        .rela.plt       :
    {
      *(.rela.plt)
    }
  .init_array     :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array     :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array))
    PROVIDE_HIDDEN (__fini_array_end = .);
  }
  .jcr            : { KEEP (*(.jcr)) }

        .init           :
        {
                KEEP (*(.init))
        } =0
 .plt            :  { *(.plt) }
        .dynamic : { *(.dynamic) } :data :dynamic
        .got            : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) } 
:got
        .data : { *(.data) } :data
}

the machine generated code for main looks as follows (objdump -D):

0000015c <main>:
 15c:   b508            push    {r3, lr}
 15e:   f000 e888       blx     270 <__libc_fini_array+0xfc>
 162:   2001            movs    r0, #1
 164:   bd08            pop     {r3, pc}
 166:   bf00            nop


instruction at  15e:   seems incorrect to me, since M4 only branches using 
a register   blx{cond} Rm, (M3 seems to be ok with label aswell.)

Anyone who can tell me what is wrong and if there is a workaround for this 
?

Ive tried to use -mlong-calls, and it produces:

00000164 <main>:
 164:   b508            push    {r3, lr}
 166:   f240 237c       movw    r3, #636        ; 0x27c
 16a:   f2c0 0300       movt    r3, #0
 16e:   4798            blx     r3
 170:   2001            movs    r0, #1
 172:   bd08            pop     {r3, pc}


This looks OK except for the address in R3 not being rellative, since it's 
absolute it's not correct either (or am I missing something)



BR
Matias

Re: gcc Cortex M4 bug ?

[Kai Ruottu]

13.6.2013 12:25, matti h kirjoitti:
> Hi,
> Im trying to implement a dynamic linker for M4 mcu's.
> But the generated code from gcc seems incorrect to me: im compiling using
> arm-none-eabi-gcc: -mcpu=cortex-m4 -mthumb -O2 -ggdb  -Wstrict-prototypes
> -Wunused-parameter -lmylib main.c -o test

For me this all looks insane :(

I would expect the 'arm-eabi' target being purely static and not knowing 
anything about
shared libraries and dynamic linking, something equivalent to the 
'arm-elf' target but with
somehow different object format. Meanwhile targets like 'arm-linux*', 
'arm-*bsd' etc. will
support dynamic linking. If we look at the Wikipedia page :

http://en.wikipedia.org/wiki/Application_binary_interface

there is told :

"The main differences of an EABI with respect to an ABI for general 
purpose operating
systems are that privileged instructions are allowed in application 
code, dynamic linking
is not required (sometimes it is completely disallowed), and a more 
compact stack frame
organization is used to save memory."

So if you change your target choice for instance to 'arm-linux-gnueabi' 
then you of course
can produce shared libraries (.so  files) etc. for some "equivalent" own 
operating system
which uses the same object format...

Re: gcc Cortex M4 bug ?

[Ilija Kocho]

On 13.06.2013 18:48, Kai Ruottu wrote:
> 13.6.2013 12:25, matti h kirjoitti:
>> Hi,
>> Im trying to implement a dynamic linker for M4 mcu's.
>> But the generated code from gcc seems incorrect to me: im compiling
>> using
>> arm-none-eabi-gcc: -mcpu=cortex-m4 -mthumb -O2 -ggdb 
>> -Wstrict-prototypes
>> -Wunused-parameter -lmylib main.c -o test
>
> For me this all looks insane :(
>
> I would expect the 'arm-eabi' target being purely static and not
> knowing anything about
> shared libraries and dynamic linking, something equivalent to the
> 'arm-elf' target but with
> somehow different object format. Meanwhile targets like 'arm-linux*',
> 'arm-*bsd' etc. will
> support dynamic linking. If we look at the Wikipedia page :
>
> http://en.wikipedia.org/wiki/Application_binary_interface
>
> there is told :
>
> "The main differences of an EABI with respect to an ABI for general
> purpose operating
> systems are that privileged instructions are allowed in application
> code, dynamic linking
> is not required (sometimes it is completely disallowed), and a more
> compact stack frame
> organization is used to save memory."

/Not required/ doesn't mean /not desirable/ (though /disallowed/
implies). It also doesn't mean that EABI hinders dynamic object loading.
An example is eCos (http://ecos.sourceware.org) that uses ARM EABI and
yet supports dynamic object loading.

Ilija