This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa mudflap] preferred technique for wrapping symbols?
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 14 Aug 2002 08:57:25 -0600
- Subject: Re: [tree-ssa mudflap] preferred technique for wrapping symbols?
- Reply-to: law at redhat dot com
In message <20020814143936.GA3576@tornado.toronto.redhat.com>, Diego Novillo wr
ites:
>On Tue, 13 Aug 2002, Frank Ch. Eigler wrote:
>
>> 2002-08-13 Frank Ch. Eigler <fche@redhat.com>
>>
>> * gcc.c (MFWRAP_SPEC, MFLIB_SPEC): New macros, splitting MFLIB_SPEC.
>> (mfwrap_spec, mflib_spec): Define corresponding vars.
>> (static_specs): Define correponding spec aliases.
>> (LINK_COMMAND_SPEC): Include -fmudflap refs to new spec aliases.
>> (cpp_unique_options): Move -fmudflap MFCPP_SPEC clause here.
>> (cc1_options): Move -fmudflap MFCC1_SPEC clause here.
>> (MFCC1_SPEC, MFCPP_SPEC, MFLIB_SPEC): Remove macros and uses.
>>
>Not really my area, but if it bootstraps and doesn't cause
>regressions, then I guess it's OK.
>
>Actually, I would like to get some opinions on whether there is a
>different way of solving the problem. IIUC, we need to intercept
>calls to common library functions to do some bookkeeping, but we
>can't really do the wrapping at compile time, right?
>
>What is exactly what we need to do in terms of bookkeeping? Why
>do we care about code that we cannot process at compile time?
>Could you give an example?
Given that we're using an instrumentation strategy (thus to check something
you have to recompile/relink it), you might be able to use the linker
function wrapping capabilities. Basically it allows you to intercept calls
to interesting functions and send them elsewhere.
Jeff