This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
>>>>> "Kenneth" == Kenneth Porter <kenneth_porter@kensingtonlabs.com> writes: Kenneth> On Fri, 27 Nov 1998 15:04:06 GMT, Bart Veer wrote: >> 4) limited protection support, primarily for debugging >> purposes, for example the ability to invalidate certain parts >> of the address space like location 0. Kenneth> I'd add the ability to write-protect code in RAM once Kenneth> it's read in, both for debugging and to protect it from Kenneth> wild pointers in the field. Same thing for memory-mapped Kenneth> non-volatile parameter memories (ie. EEPROM). These would certainly be useful, although write-protecting code can make life a bit more interesting for gdb. Kenneth> Read-protecting code (ie. limiting it to execute-only Kenneth> access) would be useful in chasing wild read pointers. Kenneth> (BTW, can GCC store vtables in non-code read-only memory, Kenneth> so that it can have different access rights than code or Kenneth> data pages? Such memory would hold read-only data objects Kenneth> like strings and function pointers.) For ELF-based targets I believe that vtables are already put in the .rodata section, just like strings etc. It would then be up to the linker script to put this section at a suitable location in memory so that it can be write-protected - including worrying about minimum page sizes etc. Bart Veer // eCos net maintainer