This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Problem linking eCos application
- From: Thomas Koeller <thomas at koeller dot dyndns dot org>
- To: ecos-discuss at sources dot redhat dot com
- Date: Thu, 8 May 2003 00:18:24 +0200
- Subject: [ECOS] Problem linking eCos application
- Organization: Basler Vision Technologies AG
- Reply-to: thomas dot koeller at baslerweb dot com
I have come across a strange problem when building an eCos
application for the ARM AT91 target. I noticed that code placed
in section .text is misaligned. Here is an excerpt from the map
file that illustrates the problem:
.text 0x00008040 0x10eb0
0x00008040 _stext = <code 335> (.)
0x00008040 PROVIDE (__stext, <code 335> (.))
*(.text*)
.text 0x00008040 0x4a4 /projects/ecos-devel/tkoeller/mk2/ecos/build/install/kernel-debug/mk2-kernel-ram-install/lib/vectors.o
0x00008409 hal_interrupt_stack_call_pending_DSRs
0x00008469 __gccmain
0x00008175 reset_platform
0x0000806d reset_vector
0x00008475 _sp
0x0000846d _psr
0x0000809d start
There is this mysterious, odd-sized gap between the start of the
.text section at 0x00008040 and reset_vector at 0x0000806d, and all
labels are placed at odd addresses. In vectors.S I found the
following:
.text
// Startup code which will get the machine into supervisor mode
.global reset_vector
.type reset_vector,function
reset_vector:
PLATFORM_SETUP1 // Early stage platform initialization
// which can set DRAM size at 0x40
// see <cyg/hal/hal_platform_setup.h>
Since this is the first and only reference to .text in this file,
I would have expected reset_vector to be located at the very
beginning of that section. The problem does only show for debug
builds (-O0 -ggdb3), not for release builds (-O3), where everything
is properly aligned. None of the other sections (and there is a lot
of those, as I am compiling with -ffunction-sections) shows this
kind of misalignment:
There is another, possibly unrelated problem: much later in the map
file the following lines appear:
.text 0x0001476c 0x81 /projects/ecos-devel/tkoeller/mk2/ecos/build/install/kernel-debug/mk2-kernel-ram-install/lib/libtarget.a(hal_arm_arch_context.o)
0x000147d5 hal_setjmp
0x000147b5 hal_thread_load_context
0x00014799 hal_thread_switch_context
0x000147e1 hal_longjmp
*fill* 0x000147ed 0x3 00
- odd addressses and a gap at the beginning again -, and finally:
.text 0x00015398 0xb0 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_divsi3.o)
0x00015398 __divsi3
.text 0x00015448 0xd4 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_modsi3.o)
0x00015448 __modsi3
.text 0x0001551c 0x4 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_dvmd_tls.o)
0x0001551c __div0
.text 0x00015520 0x50 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_ashrdi3.o)
0x00015520 __ashrdi3
.text 0x00015570 0x654 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_udivdi3.o)
0x00015570 __udivdi3
.text 0x00015bc4 0x65c /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_umoddi3.o)
0x00015bc4 __umoddi3
.text 0x00016220 0x98 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_udivsi3.o)
0x00016220 __udivsi3
.text 0x000162b8 0xc0 /tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-ecos-elf/3.2.2/libgcc.a(_umodsi3.o)
0x000162b8 __umodsi3
Shouldn't all references to one particular section be concatenated?
Is this a side effect of -ffunction-sections? I am using gcc-3.2.2
and binutils 2.13.2.1, all built from sources (on Linux).
I'd appreciate very much any help anybody can give!
tk
--
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Phone +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss