This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Multiple instances of libc (ELF shared object)


In article <37FE4E5A.E2F54AF8@bga.com> Arthur Gold  <agold@bga.com> wrote:
>... 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.

A much-less-head-achey way to do this is to enumerate all of the
calls you want to make directly, then write those yourself using
some *other* name:

		.global __trace_mprotect
	__trace_mprotect:
		push	$SYS_mprotect
		chmk
		bcc	0f
		negl	$1,r0
	0:	ret

		.global __trace_write
	__trace_write:
		push	$SYS_write
		chmk
		bcc	0f
		negl	$1,r0
	0:	ret
	/* etc */

Assemble your new system call stubs and call *those* functions from
your trace code.  Once you have done that, only those functions
whose names do *not* fit your special, easily-recognized pattern
(here __trace_*) get traced.

(Note that you may need to learn the local assembly language and
system call conventions.  The above are sort of a vague approximation
to ones for the VAX, just so that no one will try to use them directly.)
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167
http://claw.bsdi.com/torek/  (not always up)	I report spam to abuse@.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]