[ECOS] Memory Map Urgent!

John Carter john.carter@tait.co.nz
Thu Dec 9 00:40:00 GMT 2004

On Wed, 8 Dec 2004, Ruchika Singh wrote:

> I am interested in pulling out all information related to a particular thread
> that might be stored in any of the sections and hence using it.

The trouble with threads is they occupy exactly the same memory space as 
each other. Even the stacks are just array's in the .bss section. Cute, 
but messy. I much prefer unix processes to threads if I can do it.

> So I am wondering what logic if any...decides where thread related data would
> go in these sections and where can I find it.

The hard thing for most people to get is the compiler and the linker are 
completely thread _unaware_. They know absolutely _nothing_ about threads!

Say this to your self repeatedly over and over again until it scares you. 
"The compiler and linker believe everything is single threaded!"

So long as the result obeys the C semantics for a single thread, the 
compiler linker can put data where they like, reorder the code as they like, put things in 
registers as they like, optimize away as they like, inline things as they 
like, entirely without consideration for multiple threads. (Not even the 
existence "volatile" keyword alters what I have said above!)

As far as the compiler and linker are concerned everything is just single 
threaded. Thus unless you have strictly obeyed some convention like 
confining each thread to certain .o files or assigned each 
particular threads data to particular section using the __attribute__ 
extension, you are out of luck.

> I am using intel xscale 80200 (arm compliant) processor and GNU .
> ALso you mentioned about malloc placing data at end of .bss/.data section. Are
> there any linker scripts associated with it that specify this region. Where
> can i get more information about this.

I'm using sparc/leon so I haven't explore that side of ecos, but trying ....
find /opt/ecos/ecos-2.0/packages/hal/arm/xscale -name '*.ldi'

I'm not sure which variant you are working with so let's take
for example...

// eCos memory layout - Tue Sep 05 18:46:49 2000

// This is a generated file - do not edit

#include <cyg/infra/cyg_type.inc>

     ram  : ORIGIN = 0xA0000000, LENGTH = 0x2000000
     rom  : ORIGIN = 0x00000000, LENGTH = 0x800000

     SECTION_rom_vectors (ram, 0xA0000000, AT(0x00000000))   // vector page gets remapped from ROM to RAM
     SECTION_text (rom, 0x00002000, LMA_EQ_VMA)
     SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_fixed_vectors (rom, 0x20, LMA_EQ_VMA)
     SECTION_data (ram, 0xA000A000, FOLLOWING (.gcc_except_table))
     SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
//    CYG_LABEL_DEFN(__pci_window) = 0xf00000; . = CYG_LABEL_DEFN(__pci_window) + 0x100000;

The way I read that is it is saying this thing has RAM at address
0xA0000000 for 0x2000000 bytes, the heap starts after the bss section
at label __heap1 until the end of ram.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

The universe is absolutely plastered with the dashed lines exactly one
space long.

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

More information about the Ecos-discuss mailing list