www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/07/09/19:31:32

Xref: news2.mv.net comp.os.msdos.djgpp:5787
From: alaric AT abwillms DOT demon DOT co DOT uk (Alaric B. Williams)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Locking RAM for hardware interrupts
Date: Tue, 09 Jul 1996 21:59:32 GMT
Lines: 60
Message-ID: <836949498.23711.1@abwillms.demon.co.uk>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 960709084543 DOT 1036F-100000 AT is>
NNTP-Posting-Host: abwillms.demon.co.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
>There is another approach: get the sample interrupt handlers donated by 
>Martynas Kunigelis and use them as starting point.  This is available 
>from the DJGPP ftp server as
> ftp://ftp.delorie.com/pub/djgpp/contrib/sample-interrupt-handlers-v2.zip

Presumably, their approach is not too popular, though, since I've only
heard of the above methods!

>If that tutorial is not good enough, maybe it could be improved by people 
>who use it?  Maybe even by you?

I've a flair for writing; I'd be pleased to have a bash at it.

>You can do that yourself, using the symbols `start' and `etext':

>	extern unsigned start __asm__ ("start");
>	extern int etext;

>`start' is defined on crt0.s and `etext' is defined by the linker.  Use
>the addresses of these two to lock the code. 

>> Lock the lot, and leave the programmer responsible
>> for locking dynamically allocated blocks (which are usually the
>> candidates for paging, since they can be huge bitmaps etc. unlikely to
>> be declared as static data).

>I'm not sure this is a safe solution for every program.  There might be 
>cases when you don't really have control of all the data that is touched 
>by the interrupt handler.

Well, anything dynamically allocated would have to be locked manually,
as would pointers into other images (rare, but possible, I guess). But
both of those tend to be very well defined memory addresses. The real
problem is in locking the functions; for GCC does not give any
guarantees about contiguity (although it does make functions
contiguous, will it in the future??), and a function requested inlined
that the handler uses might just not be inlined for some reason -
'inline' is only a request, not a command - in which case the handler
would be using a piece of code outside it's own extent.

Et Cetera.


To summarise:

An image lock would be slightly overkill, but would be a security
blanket. Anything outside the image can be locked much more precisely,
in general.

Comments?


ABW
--
I have become... Comfortably numb...

Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
<A HREF="http://www.hardcafe.co.uk/Alaric/">http://www.hardcafe.co.uk/Alaric/</A>

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019