How to control location of startup code?
Toralf Lund
toralf@procaptura.com
Wed Mar 31 14:40:00 GMT 2004
Richard Earnshaw wrote:
>>>>Is there any way to control how the default startup code ends up in
>>>>
>>>>
>> the output file/the virutal address it gets and/or what output
>> section it's included in?
>>
>>I do it by putting it in a seperate segment. More specifically, I have
>>my own "crt0.s" it contains the reset vector and other IRQ like things
>>below is the relavent snippit in ARM assembly
>>
>>
>>
>>
>>>> .section .vectors
>>>>
>>>>
>[...]
>
>
>>The *PROBLEM* with this is by default the '.vectors' segment is not
>>tagged as loadable perhaps there is a way to do this in GAS, it was
>>not obvious to me.
>>
>>
>>
>
>You need to set the section flags when you create the section, something
>like:
>
> .section .vectors, code, "ax"
>
>which tells the assembler that the section contains code, has to be
>_A_llocated at load time and is e_X_ecutable.
>
>R.
>
>
OK. Thanks to you both.
I really think there ought to be some way to match the startup code by
file name in the linker script, though... Also, in the meantime, I've
started wonder if I raelly want to handle crt0 this way. The alternative
is to keep it in the normal code section, and have something like
vectors:
ldr pc, Reset_Addr
ldr pc, Undefined_Addr /* Undefined instructions */
ldr pc, SWI_Addr
ldr pc, Prefetch_Addr /* Prefetch abort*/
ldr pc, Abort_Addr /* Data abort */
nop /* Reserved vector */
ldr pc, IRQ_Addr
ldr pc, FIQ_Addr
[ ... ]
resetHandler:
[ initial system setup ]
ldr pc, Start_Addr
.align 0
Reset_Addr: .word resetHandler
[ ... ]
Start_Addr: .word _start
in a separate file, and direct the associated object code to a different
output section (which is easy.) Actually, I'm quite sure I want to keep
the vectors separate, the question is really whether to target vectors
*and* crt0 for the area starting at address 0, or just the vectors.
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
More information about the crossgcc
mailing list