This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
eCOS(fixed_vector section) realted GNU question. Thanks a lot.
- From: "QiangHuang" <jameshq at liverpool dot ac dot uk>
- To: "Ecos-Discuss" <ecos-discuss at sources dot redhat dot com>
- Date: Mon, 19 May 2003 14:29:14 +0100
- Subject: [ECOS] eCOS(fixed_vector section) realted GNU question. Thanks a lot.
Hi Gary:
The following is a email I posted long time ago asking about the GNU
related question. May I ask you a little question? thanks a lot.
I noticed that when I building a ecos RAM startup(ARM based) program the
virtual vector table should be initialized by RedBoot running on the board,
so the ecos application don't need to initialise the virtual vector. As I
saw from the vectors.S file there is a section call .fixed_vector
.section ".fixed_vectors"
// Interrupt/exception VSR pointers
.globl hal_vsr_table
hal_vsr_table:
.rept 8
.long 0
.endr
...
.balign 16
#ifdef CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT
// Vectors used to communicate between eCos and ROM environments
.globl hal_virtual_vector_table
hal_virtual_vector_table:
.rept CYGNUM_CALL_IF_TABLE_SIZE
.long 0
.endr
#endif
...
when building the ecos RAM application this section also defined in the ecos
and start from 0x20, when I built the application I use arm-elf-objdump -h
a.out and got the result:
...
7 .fixed_vectors 00000140 00000020 00000020 00392b80 2**5
CONTENTS, READONLY
8 .rom_vectors 00000040 00040000 00040000 00008000 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .text 00058b00 00040040 00040040 00008040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
....
Q1.
The fixed_vectors section is marked as "CONTENTS, READONLY" Does this mean
this section is not to be loadded with the initialisation (default value)?
And I checked with the a.srec(using arm-elf-objcopy) file and noticed that
there is nothing to be loadded into this memory address (start from 0x20),
so I guess that this section is not loadded with anything when the program
to be loadded into memory. So when loading the RAM based ecos application
the content of this memory address (0x20) left as it was intialissed by
RedBoot(virtual vector). Am I right?
Q2.
when defining this section as:
hal_virtual_vector_table:
.rept CYGNUM_CALL_IF_TABLE_SIZE
.long 0
.endr
Is the ".long 0" stand for the default value is "0"? If so why this section
is defined with **default value** but not end up in the binary? or the
default value get loadded into 0x20? Does it matter if this changed to
".long 0x12" (does this will cause 0x12 to be loadded into that address)?
maybe I am wrong with assembly language directive).
Q3.
If fixed_vector section is to be loadded into 0x20 with its default value 0,
then will ecos ram application overwrite the virtual vector table
initialised by RedBoot?
I am so sorry to bother you about this basic question. I do hope I can get
some help about this. Thank you very much.
On Tue, 2001-12-11 at 13:52, HuangQiang wrote:
> First thank you very much Gray.
>
> Will the size of binary file = sum of each section of the a.out (image
file)
> ??
>
> Or any relation between binary file size and the sections in the a.out
> (image file)?
> Why the debug appeared in the command output (arm-elf-objdump -h) that I
> havn't include '-g' for creating debug information? and should the debug
> section be count into if calculating the size of the file?
>
Only the sections marked 'LOAD' will show up in the binary file &/or
memory. These would be .fixed_vectors thru .rodata1 in your example.
In this example, the loadable sections are about 0x1800 or 6K, just
about what you got with "ls -l"
> e.g
> arm-elf-objdump -h
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .debug_aranges 00000368 00000000 00000000 000097c4 2**0
> CONTENTS, READONLY, DEBUGGING
> 1 .debug_pubnames 0000052c 00000000 00000000 00009b2c 2**0
> CONTENTS, READONLY, DEBUGGING
> 2 .debug_info 00008c4d 00000000 00000000 0000a058 2**0
> CONTENTS, READONLY, DEBUGGING
> 3 .debug_abbrev 00000c86
> xxxxxxxxxxxxxx
> 4 .debug_line 00002c70
> xxxxxxxxxxxxxx
> 5 .fixed_vectors 00000140
> xxxxxxxxxxxxxx
> 6 .rom_vectors 00000040
> xxxxxxxxxxxxxx
> 7 .text 00001650
> xxxxxxxxxxxxxx
> 8 .fini 00000000
> xxxxxxxxxxxxxx
> 9. .rodata 00000011
> xxxxxxxxxxxxxx
> 10 .rodata1 00000000
> xxxxxxxxxxxxxx
> 11 .fixup 00000000
> xxxxxxxxxxxxxx
> 12 .gcc_except_table 00000000
> xxxxxxxxxxxxxx
> 13 .data 00000120
> xxxxxxxxxxxxxx
> 14 .bss 00008180
> xxxxxxxxxxxxxx
>
>
>
> ls -l
>
> b size 6084
>
> Any relation ship between those two sizes?
>
> Thanks a lot!
>
> best regards!
>
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss