* gcc Cortex M4 bug ?
@ 2013-06-13 9:25 matti h
2013-06-13 16:50 ` Kai Ruottu
0 siblings, 1 reply; 3+ messages in thread
From: matti h @ 2013-06-13 9:25 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gcc Cortex M4 bug ?
2013-06-13 9:25 gcc Cortex M4 bug ? matti h
@ 2013-06-13 16:50 ` Kai Ruottu
2013-06-14 13:37 ` Ilija Kocho
0 siblings, 1 reply; 3+ messages in thread
From: Kai Ruottu @ 2013-06-13 16:50 UTC (permalink / raw)
To: gcc-help
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...
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: gcc Cortex M4 bug ?
2013-06-13 16:50 ` Kai Ruottu
@ 2013-06-14 13:37 ` Ilija Kocho
0 siblings, 0 replies; 3+ messages in thread
From: Ilija Kocho @ 2013-06-14 13:37 UTC (permalink / raw)
To: Kai Ruottu; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-06-14 13:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-13 9:25 gcc Cortex M4 bug ? matti h
2013-06-13 16:50 ` Kai Ruottu
2013-06-14 13:37 ` Ilija Kocho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).