Date: Sun, 16 Apr 2000 10:20:55 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Alexei A. Frounze" cc: djgpp AT delorie DOT com Subject: Re: Help with Inline ASM... In-Reply-To: <38F747E2.7793F51B@mtu-net.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Fri, 14 Apr 2000, Alexei A. Frounze wrote: > Please read all the following text until its end. Then reply. I thought I always did that, no need to remind me. > You're right, we can not modify segment marked as executable/read. But since > data segment is mapped on the code segment as well, you may modify it just > uding the DS selector. Yes, this is done on purpose, so that interrupt and exception handlers could access crucial variables safely (since only CS is known to be valid in an interrupt or exception handler). The DJGPP library actually uses this to provide several important features, like signals and FP emulation. > > Btw, DJGPP doesn't use a flat memory model at all. > > Wait a minute. Some string constants are stored to the code segment by GCC. And > they are accessible in data segment as well, since data segment is mapped onto > the code segment too. > > Or do you mean, that EXE files contain all the relocation entries? > If so, why I see in each EXE only the following: > > 1. COFF header > 2. optional COFF header (for already linked programs) > 3. .text section (w/o relocation entries) > 4. .data section (w/o relocation entries) > 5. .bss section (w/o relocation entries) > 6. string table > 7. symbol table > > According to the sections, the .data section starts just after the .text section > and the .bss esctions starts just after the .data section. > > So, it's a true flat memory model We seem to use two very different definitions of what ``flat memory model'' is. According to my definition, the flat model is when any linear address can be accessed without reloading the segment registers. DJGPP doesn't allow this (for example, you need _dos_ds to access the conventional memory), so its memory model is not flat. Under that definition, flat model has nothing to do with how sections are mapped. This all was discussed to death in a thread that I mentioned in my message. I suggest to find it in the DJGPP archives and read it. > The only problem might be that code segment pages are marked as read-only. But > since sections are not always 4KB aligned and their sizes are not in 4KB blocks, > I can tell you that there is no page level protection for writing. Page-level protection is not supported by most DPMI servers, so DJGPP cannot use it. But that has nothing to do with flat memory model.