🚀 go-pugleaf

Alas, I need this functionality for a _very specific_ reason (yes, I
know it's specifically _not_ something you want to be able to do
general--and I'm quite familiar with the fact that malloc()--and
functions that _call_ malloc() "behind the scenes"--and free() will hose
ya): a need to trace library access. In order to do this, we protect the
pages containing the library's code and data and notice (and fix) the
seg faults that occur. The problem, of course, is that if you protect
the page containing mprotect(), you've locked the keys in the car! (and
if you just punt and _not_ protect that page, you lose accuracy in the
trace)...
In addition, we do _not_ want to notice accesses that occur in the
tracing code itself (i.e. while the faults are being handled). hence the
conundrum.
Further, we can always wrap malloc to either just plain forbid its use,
or to appropriately dispatch the allocation requests.
While it _is_ a hack in a certain sense, because the goal is to observe
the running code, I believe it to be a princpled one.

IOW, I'm familiar with the "why not"s...and can account for them--but I
need to do it anyway!!!!

Thanks.
--ag

John Hickin wrote:
> 
> Even Microsoft advises against this chicanery (for those with VC6 search
> on LNK4096). I doubt that the Unix community would sanction this type of
> thing either (and I don't know if Unix environments even let you do it).
> 
> Suppose, for example, that you execute:
> 
>         void* ptr = malloc(42); // malloc bound to libc #1
> 
> and subsequently do
> 
>         free( ptr );            // free bound to libc #2
> 
> You are hosed, well and truely. Similar _opportunities_, somewhat
> disguised, occur with tempnam/free and strdup/free.
> 
> Cheers, John.
> 
> Arthur Gold wrote:
> >
> > Perhaps someone can help me here.
> >
> > I have a need, within a shared object, to have multiple instances of
> > libc in my address space (this has to do with tracing library access),

-- 
Artie Gold, Austin, TX
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"