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: Regd the memory section eCos1.3.1


>    Here,
>      
>           SECTION_rodata(ram, ALIGN (0x8), LMA_EQ_VMA)
>     
>     is a READ_ONLY section in ram area. Means it is defined as  READ_ONLY
> in the linker script.

eCos totally ignores these flags. eCos use of the MMU is as simple as
possible.

You asked earlier about 'locking' pages and using the MMU to make
pages READ only etc. OK, now i will answer that question.

Think about what you want to do and the amount of implementation work
you would have to do. You want to make pages read/execute only to help
debugging to track down memory corruption. This generally falls into
the following categories

1) dereferencing null pointers so changing memory < 1K. 
2) Stack overruns
3) Heap corruption by over/under running allocated memory or using memory 
   you have free'd.
4) Sometimes, but not often, a program writes over its own text and ro 
   data segment.

4) It does not happen often, so its not really worth effort. Also see
debugging below.

The MMU will not help you with 3. 

The MMU could help you with 2), but it needs a lot of careful
setup. You stack has to be page sized and aligned on a page. It
probably has to be in virtual memory not physical so making addressing
more complex. In fact, you probably want to change the stack
management so that eCos handles it all for you. When you create a
thread you pass the size of the stack and it sorts out all the messy
details. Otherwise its just too complex. Keeping this backward
compatible will be difficult.

eCos already has some stack checking code. Its not perfect, but does
catch most problems with stack over runs. 

1) The MMU could be helpful here, but again its not simple. There are
legitimate reasons to want to write to low memory. The interrupt
vectors are there. When you install a VSR you write to this
memory. The virtual vectors are often in this area. Redboot and the
application need to be able to change this memory. The debugger also
needs to be able to change the interrupt vectors when it takes over.
To make this work, you need to find all legitimate times this memory
can be written to and enable writing, do the write and then disable
writing. That not easy.....

The debugger also needs access to all memory. To insert a breakpoint
it modify the text section. To change variables from the debugger you
need write access etc. So you would have to extend the gdb stub.

eCos uses the MMU in its simplest form. This generally means large
pages. For ARM these are 1Mbyte in size. This is too large for what
you want to do. So you would have to re-write the MMU setup code to
handle 4K pages.

What you want to do is a lot of work. MMU is a fundamental part of the
OS so making changes is not trivial. 

     Andrew


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


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