RE: Rom based Shared Library

[johnmc at sidsa dot es]

Dave

Thanks again - I do know that there is no actuall image in the elf file
for the .bss and that it was invented to save some load space as its not
necessary to have the zero initialised data in the elf file.

And you are correct that there is no actual .bss in the object file but
when the program starts to run a .bbs memory space must be created.

The program I have running in Flash will read and write to this .bss section.

The problem that I have is that my program running in Flash is built such
that the .bss section is accessed directly using PC relative code. That
means as long as I keep the .bss section at the same relative position
from the instruction accessing it - it will work. So I can load the shared
library anywhere in Flash and the PIC code will be OK. Except it will NOT
as a program running in Flash cannot write to a memory area in the same
Flash - this is a hardware limitation of running programs in Flash.

I could build the code so that the .bss is located in RAM but the trouble
is that I dont know the available space in the RAM at build time so the
.bss has to be able to be re-located to any memory space in RAM.

I have the same problem with the .data section but this is ok as the .data
section is not accessed with PC relative instructions it is accessed
through Jump vectors located in the GOT table which my dynamic loader can
update when the .data section is relocated to the new RAM address.

PHEWWWW....

Did that make any sense - what do you think - have I understood it wrong?

john









I will try to explain the system that I am building.
As I said part of the system is a shared library - this consists of
Position Independent code so that it can be loaded to the Flash wherever
there is Free memory.

On 30 March 2006 15:33, johnmc@sidsa.es wrote:
>
>> hey Dave
>
>     Hi John,
>
> [  You posted this reply only to me and forgot to Cc the list.  It's
> always
> better to keep the thread on the mailing list, because a) if I get
> something
> wrong in the discussion someone will notice and correct me before you get
> a
> false understanding, and b) it all gets stored in the list archive and
> then if
> someone has the same (or a similar) problem in the future they'll be able
> to
> find our conversation and any solution with a websearch.  I've added it
> back
> in to the Cc.  ]
>
>> As I understand the .bss section is data that can be modified and since
>> the application program (at least parts of it ) are running in Flash I
>> thought it necessary to re-locate the .bss section to RAM so that the
>> data
>> in it can be modified by code running in FLASH - or have I missed
>> something - I will be happy if you prove me wrong as leaving the .bss
>> section in Flash would make my life a whole lot easier.
>
>   There's one vital fact you don't know about .bss:  It's /all/ zeros!
> Always, at startup, the /entire/ bss section is zeros; the whole purpose
> of it
> is that the compiler puts all the zero-initialised variables in there.
> Since
> the content is always known to be all zeros, the object file doesn't
> actually
> include a .bss section at all; it just has a header to tell the
> linker/loader
> how big it needs to be.
>
>   So, you don't even need to /have/ the .bss section at all in your flash.
> Just write a memset call in your early startup code to zero out the entire
> bss
> region.
>
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....
>
>



--
For unsubscribe information see http://sourceware.org/lists.html#faq