From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: gcc on linux Date: Tue, 8 Jun 1993 02:44:00 GMT
In article <C89v9y.LMM@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>In article <1993Jun7.204515.7634@kf8nh.wariat.org>
>bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>>The concept behind purify is fairly simple: [...]
>
>While that would be a reasonable way to implement purify, I think that
>purify uses a series of calls to runtime checking routines, rather
>than signal handlers to implement what it does. I'm not positive, but
>it seems that purify runs too fast to be trapping on every data/bss
>reference.
I misspoke; I should have said that the concept *could be implemented by* it.
I also apparently didn't make clear that I intended it to only trap on
*invalid* references: a free page is left around every chunk of storage, so
that indexing off either end of malloc()ed storage causes a SEGV. How far off
the indexing can be while producing a SEGV depends on how many unmapped pages
of what size are left around each malloc()ed chunk; this is an address space
vs. reliability tradeoff, and purify wins here because it loses some speed
checking every access but won't be fooled if a wild access happens to land on
a mapped page anyway. But my concept can be done with a replacement malloc
library instead of by massaging the object code.
---As you pointed out in mail, gcc could be modified to incorporate purify
capability into the compile phase at the expense of not being able to check
object code. May I suggest that this might be easier to implement by
borrowing the jumpas code from the DLL tools distribution and modifying *that*
to insert the checking code?
++Brandon
-- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.orgIt's not too late to turn back from the "Gates" of Hell... Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?