Mail Archives: djgpp-workers/1998/03/23/01:58:30
At 09:31 3/22/1998 -0600, Charles Sandmann wrote:
>> Is that as simple as just adding `.data' before them and `.text' after? It
>> looks like it is (the code that locks them doesn't seem to care where they
>> are), but I'm not sure.
>
>I think the interrupt handler code should stay in .text. I don't want
>anything like that even close to user data, which may overwrite it.
But if it was read-only it couldn't... :)
Seriously, I meant just moving the variables between `__djgpp_hw_lock'/`end'
(or whatever) into .data. But I like Bill's idea better.
>You need to lock the new data section also (in dpmiexcp.c I think) and thus
>have labels to be able to compute the length of each properly. Bill Currie's
>suggestion of just adding all the locked stuff to a different section is
>very attractive...
It is more elegant, and easier. The only problem is it will require
everybody to upgrade their Binutils, but that might not be too bad.
Also, this way other things can use it. (Allegro won't have to resort to the
END_OF_FUNCTION kludge anymore.)
>> Other than that, can we just do something like this in, say, crt1.c?
>>
>> extern int etext asm("etext");
>>
>> void __djgpp_protect_text_section(void)
>> {
>> __djgpp_set_page_attributes((void *)0, ((unsigned)&etext) & ~4096, 1);
>> }
>
>The address (and thus length) needs to be corrected to avoid messing with the
>null protection page (so (void *)(4096)...)
Of course, duh. Missed that.
>> and then call it if the appropriate crt0 flag is set?
>
>Or not call it if the appropriate crt0 flag is set. What should the default
>be?
That's actually a good question. It seems that the default should be to
protect, just like the NULL page. But some perverse folks out there may well
have written some interesting self-modifying code, and they'll complain when
it suddenly breaks. Hmm.
>> Will `text' always be the first section, and will it always start at
>> virtual address 0?
>
>Should be first, but starts at 0x1000 not 0.
>
>> I suppose this will cause some minimal code bloat, by forcing
>> `__djgpp_set_page_attributes' to be linked, but AFAICT it's only about 2-300
>> bytes.
>
>Yep, the problem is those 20 new features at 300 bytes each become noticeable.
>But it will allow more rigorous checking and better code. Another idea which
>I considered was to "no access" (like null page) the bottom page of the stack
>which would catch many overruns. Lots of nice features which could be added...
That *would* be a nice feature. It shouldn't take *much* more code to add
it. But, OTOH, that's how Emacs got started... :)
This is tricky. There's a fine line here between what the user wants, and
what they need but won't admit to needing. The threads on the theme of "Why
is Hello World 80K?" are ubiquitous, and some users won't want more just to
help keep them from shooting themselves in the foot. ("My programs never
have bugs!") Yet that's one of the main reasons to have protected mode. Hmm...
The stack thing is a little inflationary also, since we could then say,
"Well why not protect *two* pages and catch even more overruns?" "Why not
three?" etc, etc.
On the whole, however, I think bug-protection issues like this are a good
idea. Not that DJGPP doesn't have more holes than a shotgunned swiss cheese
already, of course. ;-)
(Incidentally, when you unmap a page, does its memory get freed? I had an
idea for a malloc-checker that would protect a page after each allocation,
but if it stays allocated, that would be some HUGE memory overhead.)
Nate Eldredge
eldredge AT ap DOT net
- Raw text -