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