Re: [ECOS] eCOS(fixed_vector section) realted GNU question. Thanksa lot.

[Jonathan Larmour <jifl at eCosCentric dot com>]

QiangHuang wrote:
> 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?

Yes.

> 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?

Because of the section flags on .fixed_vectors. And there needs to be 
_some_ value in there so the linker knows the size (this isn't always 
required, but is helpful so the linker can tell us if anything overlaps 
with it).

> 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).

The value doesn't matter as it never gets used. The table is initialized 
separately. Look at hal/common/current/src/hal_if.c and search for 
CYGSEM_HAL_VIRTUAL_VECTOR_INIT_WHOLE_TABLE

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss