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]

Re: Memory Map Urgent!


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' /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80310/v2_0/include/pkgconf/mlt_arm_xscale_iq80310_ram.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80310/v2_0/include/pkgconf/mlt_arm_xscale_iq80310_rom.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80310/v2_0/include/pkgconf/mlt_arm_xscale_iq80310_roma.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80321/v2_0/include/pkgconf/mlt_arm_xscale_iq80321_ram.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80321/v2_0/include/pkgconf/mlt_arm_xscale_iq80321_ram_altmap.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80321/v2_0/include/pkgconf/mlt_arm_xscale_iq80321_rom.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/iq80321/v2_0/include/pkgconf/mlt_arm_xscale_iq80321_rom_altmap.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/mpc50/v2_0/include/pkgconf/mlt_arm_pxa2x0_mpc50_ram.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/mpc50/v2_0/include/pkgconf/mlt_arm_pxa2x0_mpc50_rom.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/npwr/v2_0/include/pkgconf/mlt_arm_xscale_npwr_ram.ldi /opt/ecos/ecos-2.0/packages/hal/arm/xscale/npwr/v2_0/include/pkgconf/mlt_arm_xscale_npwr_rom.ldi


I'm not sure which variant you are working with so let's take /opt/ecos/ecos-2.0/packages/hal/arm/xscale/npwr/v2_0/include/pkgconf/mlt_arm_xscale_npwr_rom.ldi 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>

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

SECTIONS
{
    SECTIONS_BEGIN
    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;
    SECTIONS_END
}

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


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