I have a simple program for the LPC2103 that I've been building
successfully for months with gcc 4.2, but on the switch to 4.3 (new
machine, got the latest sources, applied the interwork patch, and
rebuilt) I get a software interrupt as soon as I power the thing up.
If I break in, the thing is off in the weeds in Thumb mode. A quick
look at the .lss file produced by gcc turns up a pretty stark change
to my startup code:
OLD:
00000000 <_boot>:
// Runtime Interrupt Vectors
// -------------------------
Vectors:
b _start // reset - _start
0: ea000012 b 50 <_mainCRTStartup>
ldr pc,_undf // undefined - _undf
4: e59ff014 ldr pc, [pc, #20] ; 20 <_undf>
ldr pc,_swi // SWI - _swi
8: e59ff014 ldr pc, [pc, #20] ; 24 <_swi>
ldr pc,_pabt // program abort - _pabt
c: e59ff014 ldr pc, [pc, #20] ; 28 <_pabt>
ldr pc,_dabt // data abort - _dabt
10: e59ff014 ldr pc, [pc, #20] ; 2c <_dabt>
nop // reserved
14: e1a00000 nop (mov r0,r0)
NEW:
00000000 <__disableIRQ_from_thumb>:
0: 4778 bx pc
2: 46c0 nop (mov r8, r8)
4: ea0000c2 b 314
00000008 <__restoreIRQ_from_thumb>:
8: 4778 bx pc
a: 46c0 nop (mov r8, r8)
c: ea0000e5 b 3a8
00000010 <_boot>:
_boot:
// Runtime Interrupt Vectors
// -------------------------
Vectors:
b _start // reset - _start
10: ea000012 b 60 <_mainCRTStartup>
ldr pc,_undf // undefined - _undf
14: e59ff014 ldr pc, [pc, #20] ; 30 <_undf>
ldr pc,_swi // SWI - _swi
18: e59ff014 ldr pc, [pc, #20] ; 34 <_swi>
What gives!? The compiler has dropped those functions right before my
start up code. Should I be booting to that? I'm tracing through the
assembly now to see if it makes sense, but this is a pretty stark
change from before, so I'm just wondering if anyone else has made
this move, and if they know what's up with this?
THanks!
-R
Update to gcc-4.3.3 (from 4.2) breaks my build
Started by ●February 24, 2009
Reply by ●February 25, 20092009-02-25
l... napisa(a):
[...]
> What gives!? The compiler has dropped those functions right before my
> start up code. Should I be booting to that? I'm tracing through the
> assembly now to see if it makes sense, but this is a pretty stark
> change from before, so I'm just wondering if anyone else has made
> this move, and if they know what's up with this?
Your compiler is free to do it.
You can enforce proper order by use section attributte and proper linker script.
If you send startup code and linker script, we can help you.
Albert
[...]
> What gives!? The compiler has dropped those functions right before my
> start up code. Should I be booting to that? I'm tracing through the
> assembly now to see if it makes sense, but this is a pretty stark
> change from before, so I'm just wondering if anyone else has made
> this move, and if they know what's up with this?
Your compiler is free to do it.
You can enforce proper order by use section attributte and proper linker script.
If you send startup code and linker script, we can help you.
Albert
Reply by ●February 25, 20092009-02-25
rsturmer schrieb:
>
> 00000000 <__disableIRQ_from_thumb>:
> 0: 4778 bx pc
> 2: 46c0 nop (mov r8, r8)
> 4: ea0000c2 b 314 00000008 <__restoreIRQ_from_thumb>:
> 8: 4778 bx pc
> a: 46c0 nop (mov r8, r8)
> c: ea0000e5 b 3a8
It seems you linker script misses the veneer functions.
Also (in case of C++) 4.3 adds new section names.
Add this:
*(.glue*)
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
>
> 00000000 <__disableIRQ_from_thumb>:
> 0: 4778 bx pc
> 2: 46c0 nop (mov r8, r8)
> 4: ea0000c2 b 314 00000008 <__restoreIRQ_from_thumb>:
> 8: 4778 bx pc
> a: 46c0 nop (mov r8, r8)
> c: ea0000e5 b 3a8
It seems you linker script misses the veneer functions.
Also (in case of C++) 4.3 adds new section names.
Add this:
*(.glue*)
--
42Bastian
Note: SPAM-only account, direct mail to bs42@...
Reply by ●February 26, 20092009-02-26
Linker script followed by startup code below. Pretty much the
boilerplate for these micros...
SEARCH_DIR(./)
SEARCH_DIR(../obj/)
ENTRY(_boot)
STACK_SIZE = 0x400;
/* Memory Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x00008000
RAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00002000
}
/* Section Definitions */
SECTIONS
{
/* first section is .text which is used for code */
.text :
{
*/obj/crt0.o (.text) /* Startup code */
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
*(.glue*)
} > ROM
. = ALIGN(4);
_etext = . ;
PROVIDE (etext = .);
/* .data section which is used for initialized data */
.data : AT (_etext)
{
_data = .;
*(.data)
} > RAM
. = ALIGN(4);
_edata = . ;
PROVIDE (edata = .);
/* .bss section which is used for uninitialized data */
.bss (NOLOAD) :
{
__bss_start = . ;
__bss_start__ = . ;
*(.bss)
*(COMMON)
. = ALIGN(4);
} > RAM
. = ALIGN(4);
__bss_end__ = . ;
PROVIDE (__bss_end = .);
.stack ALIGN(256) :
{
. += STACK_SIZE;
PROVIDE (_stack = .);
} > RAM
_end = . ;
PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
}
STARTUP CODE:
.global main // int main(void)
.global _etext // -> .data initial values in ROM
.global _data // -> .data area in RAM
.global _edata // end of .data area
.global __bss_start // -> .bss area in RAM
.global __bss_end__ // end of .bss area
.global _stack // top of stack
// Stack Sizes
.set UND_STACK_SIZE, 0x00000004
.set ABT_STACK_SIZE, 0x00000004
.set FIQ_STACK_SIZE, 0x00000004
.set IRQ_STACK_SIZE, 0X00000080
.set SVC_STACK_SIZE, 0x00000004
// Standard definitions of Mode bits and Interrupt (I & F) flags in PSRs
.set MODE_USR, 0x10 // User Mode
.set MODE_FIQ, 0x11 // FIQ Mode
.set MODE_IRQ, 0x12 // IRQ Mode
.set MODE_SVC, 0x13 // Supervisor Mode
.set MODE_ABT, 0x17 // Abort Mode
.set MODE_UND, 0x1B // Undefined Mode
.set MODE_SYS, 0x1F // System Mode
.equ I_BIT, 0x80 // when I bit is set, IRQ is
disabled
.equ F_BIT, 0x40 // when F bit is set, FIQ is
disabled
.text
.code 32
.align 2
.global _boot
.func _boot
_boot:
// Runtime Interrupt Vectors
// -------------------------
Vectors:
b _start // reset - _start
ldr pc,_undf // undefined - _undf
ldr pc,_swi // SWI - _swi
ldr pc,_pabt // program abort - _pabt
ldr pc,_dabt // data abort - _dabt
nop // reserved
ldr pc,[pc,#-0xFF0] // IRQ - read the VIC
ldr pc,_fiq // FIQ - _fiq
#if 0
// Use this group for production
_undf: .word _reset // undefined - _reset
_swi: .word _reset // SWI - _reset
_pabt: .word _reset // program abort - _reset
_dabt: .word _reset // data abort - _reset
_irq: .word _reset // IRQ - _reset
_fiq: .word _reset // FIQ - _reset
#else
// Use this group for development
_undf: .word __undf // undefined
_swi: .word __swi // SWI
_pabt: .word __pabt // program abort
_dabt: .word __dabt // data abort
_irq: .word __irq // IRQ
_fiq: .word __fiq // FIQ
__undf: b . // undefined
__swi: b . // SWI
__pabt: b . // program abort
__dabt: b . // data abort
__irq: b . // IRQ
__fiq: b . // FIQ
#endif
.size _boot, . - _boot
.endfunc
// Setup the operating mode & stack.
// ---------------------------------
.global _start, start, _mainCRTStartup
.func _start
_start:
start:
_mainCRTStartup:
// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in System Mode with Interrupts Disabled
// -----------
b _start
ldr r0,=_stack
msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined Instruction Mode
mov sp,r0
sub r0,r0,#UND_STACK_SIZE
msr CPSR_c,#MODE_ABT|I_BIT|F_BIT // Abort Mode
mov sp,r0
sub r0,r0,#ABT_STACK_SIZE
msr CPSR_c,#MODE_FIQ|I_BIT|F_BIT // FIQ Mode
mov sp,r0
sub r0,r0,#FIQ_STACK_SIZE
msr CPSR_c,#MODE_IRQ|I_BIT|F_BIT // IRQ Mode
mov sp,r0
sub r0,r0,#IRQ_STACK_SIZE
msr CPSR_c,#MODE_SVC|I_BIT|F_BIT // Supervisor Mode
mov sp,r0
sub r0,r0,#SVC_STACK_SIZE
msr CPSR_c,#MODE_SYS|I_BIT|F_BIT // System Mode
mov sp,r0
// Copy initialized data to its execution address in RAM
// -----------------
#ifdef ROM_RUN
ldr r1,=_etext // -> ROM data start
ldr r2,=_data // -> data start
ldr r3,=_edata // -> end of data
1: cmp r2,r3 // check if data to move
ldrlo r0,[r1],#4 // copy it
strlo r0,[r2],#4
blo 1b // loop until done
#endif
// Clear .bss
// ----------
mov r0,#0 // get a zero
ldr r1,=__bss_start // -> bss start
ldr r2,=__bss_end__ // -> bss end
2: cmp r1,r2 // check if data to clear
strlo r0,[r1],#4 // clear 4 bytes
blo 2b // loop until done
// Call main program: main(0)
// --------------------------
mov r0,#0 // no arguments (argc = 0)
mov r1,r0
mov r2,r0
mov fp,r0 // null frame pointer
mov r7,r0 // null frame pointer for thumb
ldr r10,=main
mov lr,pc
bx r10 // enter main()
.size _start, . - _start
.endfunc
.global _reset, reset, exit, abort
.func _reset
_reset:
reset:
exit:
abort:
#if 0
// Disable interrupts, then force a hardware reset by driving P23 low
// -------------------------------
mrs r0,cpsr // get PSR
orr r0,r0,#I_BIT|F_BIT // disable IRQ and FIQ
msr cpsr,r0 // set up status register
ldr r1,=(PS_BASE) // PS Base Address
ldr r0,=(PS_PIO) // PIO Module
str r0,[r1,#PS_PCER_OFF] // enable its clock
ldr r1,=(PIO_BASE) // PIO Base Address
ldr r0,=(1<<23) // P23
str r0,[r1,#PIO_PER_OFF] // make sure pin is contolled
by PIO
str r0,[r1,#PIO_CODR_OFF] // set the pin low
str r0,[r1,#PIO_OER_OFF] // make it an output
#endif
b . // loop until reset
.size _reset, . - _reset
.endfunc
.end
--- In l..., "rsturmer" wrote:
>
> I have a simple program for the LPC2103 that I've been building
> successfully for months with gcc 4.2, but on the switch to 4.3 (new
> machine, got the latest sources, applied the interwork patch, and
> rebuilt) I get a software interrupt as soon as I power the thing up.
> If I break in, the thing is off in the weeds in Thumb mode. A quick
> look at the .lss file produced by gcc turns up a pretty stark change
> to my startup code:
>
> OLD:
> 00000000 <_boot>:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
> 0: ea000012 b 50 <_mainCRTStartup>
> ldr pc,_undf // undefined - _undf
> 4: e59ff014 ldr pc, [pc, #20] ; 20 <_undf>
> ldr pc,_swi // SWI - _swi
> 8: e59ff014 ldr pc, [pc, #20] ; 24 <_swi>
> ldr pc,_pabt // program abort - _pabt
> c: e59ff014 ldr pc, [pc, #20] ; 28 <_pabt>
> ldr pc,_dabt // data abort - _dabt
> 10: e59ff014 ldr pc, [pc, #20] ; 2c <_dabt>
> nop // reserved
> 14: e1a00000 nop (mov r0,r0)
> NEW:
> 00000000 <__disableIRQ_from_thumb>:
> 0: 4778 bx pc
> 2: 46c0 nop (mov r8, r8)
> 4: ea0000c2 b 314 00000008 <__restoreIRQ_from_thumb>:
> 8: 4778 bx pc
> a: 46c0 nop (mov r8, r8)
> c: ea0000e5 b 3a8 00000010 <_boot>:
> _boot:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
> 10: ea000012 b 60 <_mainCRTStartup>
> ldr pc,_undf // undefined - _undf
> 14: e59ff014 ldr pc, [pc, #20] ; 30 <_undf>
> ldr pc,_swi // SWI - _swi
> 18: e59ff014 ldr pc, [pc, #20] ; 34 <_swi>
> What gives!? The compiler has dropped those functions right before my
> start up code. Should I be booting to that? I'm tracing through the
> assembly now to see if it makes sense, but this is a pretty stark
> change from before, so I'm just wondering if anyone else has made
> this move, and if they know what's up with this?
>
> THanks!
>
> -R
>
boilerplate for these micros...
SEARCH_DIR(./)
SEARCH_DIR(../obj/)
ENTRY(_boot)
STACK_SIZE = 0x400;
/* Memory Definitions */
MEMORY
{
ROM (rx) : ORIGIN = 0x00000000, LENGTH = 0x00008000
RAM (rw) : ORIGIN = 0x40000000, LENGTH = 0x00002000
}
/* Section Definitions */
SECTIONS
{
/* first section is .text which is used for code */
.text :
{
*/obj/crt0.o (.text) /* Startup code */
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
*(.glue*)
} > ROM
. = ALIGN(4);
_etext = . ;
PROVIDE (etext = .);
/* .data section which is used for initialized data */
.data : AT (_etext)
{
_data = .;
*(.data)
} > RAM
. = ALIGN(4);
_edata = . ;
PROVIDE (edata = .);
/* .bss section which is used for uninitialized data */
.bss (NOLOAD) :
{
__bss_start = . ;
__bss_start__ = . ;
*(.bss)
*(COMMON)
. = ALIGN(4);
} > RAM
. = ALIGN(4);
__bss_end__ = . ;
PROVIDE (__bss_end = .);
.stack ALIGN(256) :
{
. += STACK_SIZE;
PROVIDE (_stack = .);
} > RAM
_end = . ;
PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
}
STARTUP CODE:
.global main // int main(void)
.global _etext // -> .data initial values in ROM
.global _data // -> .data area in RAM
.global _edata // end of .data area
.global __bss_start // -> .bss area in RAM
.global __bss_end__ // end of .bss area
.global _stack // top of stack
// Stack Sizes
.set UND_STACK_SIZE, 0x00000004
.set ABT_STACK_SIZE, 0x00000004
.set FIQ_STACK_SIZE, 0x00000004
.set IRQ_STACK_SIZE, 0X00000080
.set SVC_STACK_SIZE, 0x00000004
// Standard definitions of Mode bits and Interrupt (I & F) flags in PSRs
.set MODE_USR, 0x10 // User Mode
.set MODE_FIQ, 0x11 // FIQ Mode
.set MODE_IRQ, 0x12 // IRQ Mode
.set MODE_SVC, 0x13 // Supervisor Mode
.set MODE_ABT, 0x17 // Abort Mode
.set MODE_UND, 0x1B // Undefined Mode
.set MODE_SYS, 0x1F // System Mode
.equ I_BIT, 0x80 // when I bit is set, IRQ is
disabled
.equ F_BIT, 0x40 // when F bit is set, FIQ is
disabled
.text
.code 32
.align 2
.global _boot
.func _boot
_boot:
// Runtime Interrupt Vectors
// -------------------------
Vectors:
b _start // reset - _start
ldr pc,_undf // undefined - _undf
ldr pc,_swi // SWI - _swi
ldr pc,_pabt // program abort - _pabt
ldr pc,_dabt // data abort - _dabt
nop // reserved
ldr pc,[pc,#-0xFF0] // IRQ - read the VIC
ldr pc,_fiq // FIQ - _fiq
#if 0
// Use this group for production
_undf: .word _reset // undefined - _reset
_swi: .word _reset // SWI - _reset
_pabt: .word _reset // program abort - _reset
_dabt: .word _reset // data abort - _reset
_irq: .word _reset // IRQ - _reset
_fiq: .word _reset // FIQ - _reset
#else
// Use this group for development
_undf: .word __undf // undefined
_swi: .word __swi // SWI
_pabt: .word __pabt // program abort
_dabt: .word __dabt // data abort
_irq: .word __irq // IRQ
_fiq: .word __fiq // FIQ
__undf: b . // undefined
__swi: b . // SWI
__pabt: b . // program abort
__dabt: b . // data abort
__irq: b . // IRQ
__fiq: b . // FIQ
#endif
.size _boot, . - _boot
.endfunc
// Setup the operating mode & stack.
// ---------------------------------
.global _start, start, _mainCRTStartup
.func _start
_start:
start:
_mainCRTStartup:
// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in System Mode with Interrupts Disabled
// -----------
b _start
ldr r0,=_stack
msr CPSR_c,#MODE_UND|I_BIT|F_BIT // Undefined Instruction Mode
mov sp,r0
sub r0,r0,#UND_STACK_SIZE
msr CPSR_c,#MODE_ABT|I_BIT|F_BIT // Abort Mode
mov sp,r0
sub r0,r0,#ABT_STACK_SIZE
msr CPSR_c,#MODE_FIQ|I_BIT|F_BIT // FIQ Mode
mov sp,r0
sub r0,r0,#FIQ_STACK_SIZE
msr CPSR_c,#MODE_IRQ|I_BIT|F_BIT // IRQ Mode
mov sp,r0
sub r0,r0,#IRQ_STACK_SIZE
msr CPSR_c,#MODE_SVC|I_BIT|F_BIT // Supervisor Mode
mov sp,r0
sub r0,r0,#SVC_STACK_SIZE
msr CPSR_c,#MODE_SYS|I_BIT|F_BIT // System Mode
mov sp,r0
// Copy initialized data to its execution address in RAM
// -----------------
#ifdef ROM_RUN
ldr r1,=_etext // -> ROM data start
ldr r2,=_data // -> data start
ldr r3,=_edata // -> end of data
1: cmp r2,r3 // check if data to move
ldrlo r0,[r1],#4 // copy it
strlo r0,[r2],#4
blo 1b // loop until done
#endif
// Clear .bss
// ----------
mov r0,#0 // get a zero
ldr r1,=__bss_start // -> bss start
ldr r2,=__bss_end__ // -> bss end
2: cmp r1,r2 // check if data to clear
strlo r0,[r1],#4 // clear 4 bytes
blo 2b // loop until done
// Call main program: main(0)
// --------------------------
mov r0,#0 // no arguments (argc = 0)
mov r1,r0
mov r2,r0
mov fp,r0 // null frame pointer
mov r7,r0 // null frame pointer for thumb
ldr r10,=main
mov lr,pc
bx r10 // enter main()
.size _start, . - _start
.endfunc
.global _reset, reset, exit, abort
.func _reset
_reset:
reset:
exit:
abort:
#if 0
// Disable interrupts, then force a hardware reset by driving P23 low
// -------------------------------
mrs r0,cpsr // get PSR
orr r0,r0,#I_BIT|F_BIT // disable IRQ and FIQ
msr cpsr,r0 // set up status register
ldr r1,=(PS_BASE) // PS Base Address
ldr r0,=(PS_PIO) // PIO Module
str r0,[r1,#PS_PCER_OFF] // enable its clock
ldr r1,=(PIO_BASE) // PIO Base Address
ldr r0,=(1<<23) // P23
str r0,[r1,#PIO_PER_OFF] // make sure pin is contolled
by PIO
str r0,[r1,#PIO_CODR_OFF] // set the pin low
str r0,[r1,#PIO_OER_OFF] // make it an output
#endif
b . // loop until reset
.size _reset, . - _reset
.endfunc
.end
--- In l..., "rsturmer" wrote:
>
> I have a simple program for the LPC2103 that I've been building
> successfully for months with gcc 4.2, but on the switch to 4.3 (new
> machine, got the latest sources, applied the interwork patch, and
> rebuilt) I get a software interrupt as soon as I power the thing up.
> If I break in, the thing is off in the weeds in Thumb mode. A quick
> look at the .lss file produced by gcc turns up a pretty stark change
> to my startup code:
>
> OLD:
> 00000000 <_boot>:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
> 0: ea000012 b 50 <_mainCRTStartup>
> ldr pc,_undf // undefined - _undf
> 4: e59ff014 ldr pc, [pc, #20] ; 20 <_undf>
> ldr pc,_swi // SWI - _swi
> 8: e59ff014 ldr pc, [pc, #20] ; 24 <_swi>
> ldr pc,_pabt // program abort - _pabt
> c: e59ff014 ldr pc, [pc, #20] ; 28 <_pabt>
> ldr pc,_dabt // data abort - _dabt
> 10: e59ff014 ldr pc, [pc, #20] ; 2c <_dabt>
> nop // reserved
> 14: e1a00000 nop (mov r0,r0)
> NEW:
> 00000000 <__disableIRQ_from_thumb>:
> 0: 4778 bx pc
> 2: 46c0 nop (mov r8, r8)
> 4: ea0000c2 b 314 00000008 <__restoreIRQ_from_thumb>:
> 8: 4778 bx pc
> a: 46c0 nop (mov r8, r8)
> c: ea0000e5 b 3a8 00000010 <_boot>:
> _boot:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
> 10: ea000012 b 60 <_mainCRTStartup>
> ldr pc,_undf // undefined - _undf
> 14: e59ff014 ldr pc, [pc, #20] ; 30 <_undf>
> ldr pc,_swi // SWI - _swi
> 18: e59ff014 ldr pc, [pc, #20] ; 34 <_swi>
> What gives!? The compiler has dropped those functions right before my
> start up code. Should I be booting to that? I'm tracing through the
> assembly now to see if it makes sense, but this is a pretty stark
> change from before, so I'm just wondering if anyone else has made
> this move, and if they know what's up with this?
>
> THanks!
>
> -R
>
Reply by ●February 26, 20092009-02-26
Dnia 26-02-2009, czw o godzinie 04:44 +0000, rsturmer napisaĆ(a):
[...]
> .text :
> {
> */obj/crt0.o (.text) /* Startup code */
> *(.text) /* remaining code */
> *(.rodata) /* read-only data (constants) */
> *(.rodata*)
> *(.glue_7)
> *(.glue_7t)
> *(.glue*)
> } > ROM
[...]
> STARTUP CODE:
[...]
> .text
> .code 32
> .align 2
>
> .global _boot
> .func _boot
> _boot:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
[...]
I don't know from __disableIRQ_from_thumb function is (no in newlib, no
in gcc-core)
but if match the rule:
*/obj/crt0.o (.text) /* Startup code */
and the library contain it is before your crt0.o you got it.
Try for example rename your startup from crt0.S to mycrt0.S and add in
linker script
*mycrt0.o(.text)
before
*/obj/crt0.o (.text) /* Startup code */
--
Albert
>
[...]
> .text :
> {
> */obj/crt0.o (.text) /* Startup code */
> *(.text) /* remaining code */
> *(.rodata) /* read-only data (constants) */
> *(.rodata*)
> *(.glue_7)
> *(.glue_7t)
> *(.glue*)
> } > ROM
[...]
> STARTUP CODE:
[...]
> .text
> .code 32
> .align 2
>
> .global _boot
> .func _boot
> _boot:
>
> // Runtime Interrupt Vectors
> // -------------------------
> Vectors:
> b _start // reset - _start
[...]
I don't know from __disableIRQ_from_thumb function is (no in newlib, no
in gcc-core)
but if match the rule:
*/obj/crt0.o (.text) /* Startup code */
and the library contain it is before your crt0.o you got it.
Try for example rename your startup from crt0.S to mycrt0.S and add in
linker script
*mycrt0.o(.text)
before
*/obj/crt0.o (.text) /* Startup code */
--
Albert
>
Reply by ●February 26, 20092009-02-26
Albert Bartoszko wrote:
> Try for example rename your startup from crt0.S to mycrt0.S and add in
> linker script
> *mycrt0.o(.text)
> before
> */obj/crt0.o (.text) /* Startup code */
You could also just put the startup code in its own separate section.
This is easily done by changing the ".text" line in the startup code to:
.section .startup
Now the text output section of the linker script can become:
.text :
{
KEEP(*(.startup))
*(.text .text.* .gnu.linkonce.t.*)
*(.rodata .rodata.*)
*(.glue_7t)
*(.glue_7)
} >ROM
Note the use of KEEP to prevent the linker from throwing the startup
code away. Also, the addition of the ".*" parts, to catch sections when
you use the "-ffunction-sections" and "-fdata-sections" compiler options.
The advantage of this approach is that it no longer requires a specific
name for your startup file. We used to use the named-file method and
had people complain at one point that their code simply no longer worked
-- quite a tricky problem to track down when they don't mention the fact
that they have renamed the startup file.
Pete
--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
> Try for example rename your startup from crt0.S to mycrt0.S and add in
> linker script
> *mycrt0.o(.text)
> before
> */obj/crt0.o (.text) /* Startup code */
You could also just put the startup code in its own separate section.
This is easily done by changing the ".text" line in the startup code to:
.section .startup
Now the text output section of the linker script can become:
.text :
{
KEEP(*(.startup))
*(.text .text.* .gnu.linkonce.t.*)
*(.rodata .rodata.*)
*(.glue_7t)
*(.glue_7)
} >ROM
Note the use of KEEP to prevent the linker from throwing the startup
code away. Also, the addition of the ".*" parts, to catch sections when
you use the "-ffunction-sections" and "-fdata-sections" compiler options.
The advantage of this approach is that it no longer requires a specific
name for your startup file. We used to use the named-file method and
had people complain at one point that their code simply no longer worked
-- quite a tricky problem to track down when they don't mention the fact
that they have renamed the startup file.
Pete
--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Reply by ●February 26, 20092009-02-26
Created a .startup section as you described, used KEEP(), put the
.text.* entry in there, and same result. Still have those same 2
functions linked in at address 0x0. Any further thoughts?
-R
--- In l..., Peter Vidler wrote:
>
> Albert Bartoszko wrote:
> > Try for example rename your startup from crt0.S to mycrt0.S and add in
> > linker script
> > *mycrt0.o(.text)
> > before
> > */obj/crt0.o (.text) /* Startup code */
>
> You could also just put the startup code in its own separate section.
> This is easily done by changing the ".text" line in the startup code to:
>
> .section .startup
>
> Now the text output section of the linker script can become:
>
> .text :
> {
> KEEP(*(.startup))
> *(.text .text.* .gnu.linkonce.t.*)
> *(.rodata .rodata.*)
> *(.glue_7t)
> *(.glue_7)
> } >ROM
>
> Note the use of KEEP to prevent the linker from throwing the startup
> code away. Also, the addition of the ".*" parts, to catch sections
when
> you use the "-ffunction-sections" and "-fdata-sections" compiler
options.
>
> The advantage of this approach is that it no longer requires a specific
> name for your startup file. We used to use the named-file method and
> had people complain at one point that their code simply no longer
worked
> -- quite a tricky problem to track down when they don't mention the
fact
> that they have renamed the startup file.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>
.text.* entry in there, and same result. Still have those same 2
functions linked in at address 0x0. Any further thoughts?
-R
--- In l..., Peter Vidler wrote:
>
> Albert Bartoszko wrote:
> > Try for example rename your startup from crt0.S to mycrt0.S and add in
> > linker script
> > *mycrt0.o(.text)
> > before
> > */obj/crt0.o (.text) /* Startup code */
>
> You could also just put the startup code in its own separate section.
> This is easily done by changing the ".text" line in the startup code to:
>
> .section .startup
>
> Now the text output section of the linker script can become:
>
> .text :
> {
> KEEP(*(.startup))
> *(.text .text.* .gnu.linkonce.t.*)
> *(.rodata .rodata.*)
> *(.glue_7t)
> *(.glue_7)
> } >ROM
>
> Note the use of KEEP to prevent the linker from throwing the startup
> code away. Also, the addition of the ".*" parts, to catch sections
when
> you use the "-ffunction-sections" and "-fdata-sections" compiler
options.
>
> The advantage of this approach is that it no longer requires a specific
> name for your startup file. We used to use the named-file method and
> had people complain at one point that their code simply no longer
worked
> -- quite a tricky problem to track down when they don't mention the
fact
> that they have renamed the startup file.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>
Reply by ●February 26, 20092009-02-26
rsturmer wrote:
> Created a .startup section as you described, used KEEP(), put the
> .text.* entry in there, and same result. Still have those same 2
> functions linked in at address 0x0. Any further thoughts?
It would be useful to know where those two functions are coming from --
do you generate a map file? If not, you should be able to generate one
with an option to the linker. Can you post the (start of) the .text
section, as described by the map file?
That should tell us exactly which section the functions come from --
then you should be able to just add it to the linker script, after the
startup.
Pete
--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
> Created a .startup section as you described, used KEEP(), put the
> .text.* entry in there, and same result. Still have those same 2
> functions linked in at address 0x0. Any further thoughts?
It would be useful to know where those two functions are coming from --
do you generate a map file? If not, you should be able to generate one
with an option to the linker. Can you post the (start of) the .text
section, as described by the map file?
That should tell us exactly which section the functions come from --
then you should be able to just add it to the linker script, after the
startup.
Pete
--
Peter J. Vidler
Senior Systems Developer, TTE Systems Ltd
www.tte-systems.com
Reply by ●February 26, 20092009-02-26
Unfortunately I'm not in a position to rebuild and test right now, but
here's the beginning of the .text section from my map file (This is
slightly dated, before I made the changes in the above post):
.text 0x0000000000000000 0x2c5c
*./obj/crt0.o(.text)
.text.stub 0x0000000000000000 0x10 linker stubs
.text 0x0000000000000010 0x110 ./obj/crt0.o
0x0000000000000100 reset
0x0000000000000010 _boot
0x0000000000000060 _mainCRTStartup
0x0000000000000100 abort
0x0000000000000060 _start
0x0000000000000100 _reset
0x0000000000000100 exit
0x0000000000000060 start
*(.text)
So the section this comes from is .text.stub, and is introduced by the
linker??
--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > Created a .startup section as you described, used KEEP(), put the
> > .text.* entry in there, and same result. Still have those same 2
> > functions linked in at address 0x0. Any further thoughts?
>
> It would be useful to know where those two functions are coming from --
> do you generate a map file? If not, you should be able to generate one
> with an option to the linker. Can you post the (start of) the .text
> section, as described by the map file?
>
> That should tell us exactly which section the functions come from --
> then you should be able to just add it to the linker script, after the
> startup.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>
here's the beginning of the .text section from my map file (This is
slightly dated, before I made the changes in the above post):
.text 0x0000000000000000 0x2c5c
*./obj/crt0.o(.text)
.text.stub 0x0000000000000000 0x10 linker stubs
.text 0x0000000000000010 0x110 ./obj/crt0.o
0x0000000000000100 reset
0x0000000000000010 _boot
0x0000000000000060 _mainCRTStartup
0x0000000000000100 abort
0x0000000000000060 _start
0x0000000000000100 _reset
0x0000000000000100 exit
0x0000000000000060 start
*(.text)
So the section this comes from is .text.stub, and is introduced by the
linker??
--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > Created a .startup section as you described, used KEEP(), put the
> > .text.* entry in there, and same result. Still have those same 2
> > functions linked in at address 0x0. Any further thoughts?
>
> It would be useful to know where those two functions are coming from --
> do you generate a map file? If not, you should be able to generate one
> with an option to the linker. Can you post the (start of) the .text
> section, as described by the map file?
>
> That should tell us exactly which section the functions come from --
> then you should be able to just add it to the linker script, after the
> startup.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>
Reply by ●February 26, 20092009-02-26
Oh crap, this kind of describes my issue:
http://sourceware.org/ml/binutils/2009-02/msg00295.html
...
--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > Created a .startup section as you described, used KEEP(), put the
> > .text.* entry in there, and same result. Still have those same 2
> > functions linked in at address 0x0. Any further thoughts?
>
> It would be useful to know where those two functions are coming from --
> do you generate a map file? If not, you should be able to generate one
> with an option to the linker. Can you post the (start of) the .text
> section, as described by the map file?
>
> That should tell us exactly which section the functions come from --
> then you should be able to just add it to the linker script, after the
> startup.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>
http://sourceware.org/ml/binutils/2009-02/msg00295.html
...
--- In l..., Peter Vidler wrote:
>
> rsturmer wrote:
> > Created a .startup section as you described, used KEEP(), put the
> > .text.* entry in there, and same result. Still have those same 2
> > functions linked in at address 0x0. Any further thoughts?
>
> It would be useful to know where those two functions are coming from --
> do you generate a map file? If not, you should be able to generate one
> with an option to the linker. Can you post the (start of) the .text
> section, as described by the map file?
>
> That should tell us exactly which section the functions come from --
> then you should be able to just add it to the linker script, after the
> startup.
>
> Pete
>
> --
> Peter J. Vidler
> Senior Systems Developer, TTE Systems Ltd
> www.tte-systems.com
>