[ECOS] Memory Map Urgent!
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
// eCos memory layout - Tue Sep 05 18:46:49 2000
// This is a generated file - do not edit
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 : firstname.lastname@example.org
The universe is absolutely plastered with the dashed lines exactly one
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