This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]