Re: ld --wrap option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 12, 2013 at 10:28 AM, Greg Hopkins <Greg.Hopkins@xxxxxxx> wrote:
> Resending due to urgent need.  Please help if you can.  Thank you.
>
> -----Original Message-----
>
> I am using the ld --wrap option of a gcc-based toolchain, and the option is working as advertised, except for the cases where wrapped functions are called from within the modules in which they (the real) functions are defined. An ojbdump of the final executable disassembly shows all calls from outside of the defining module correctly resolve to __wrap_function_name, (which is currently written to then call __real_function_name to complete the execution threads.)  However, for any particular function_name, all calls to function_name from within its defining module go directly to the target, "real", function, bypassing the wrapper construct.
>
> Is there a gcc compiler/assembler/linker option to force all symbols to be undefined until link stage, which I believe would then cause all such bypassing calls to correctly link to the wrapper functions? I've tried --undefined=function_name; that didn't work; the intramodules direct calls still occurred. I also tried --defsym=function_name=__wrap_function_name, and that resulted in an infinitely loop branch-to-self in the target function.


This is going to be an assembler option, not a compiler one.  It's
going to be target-specific, and you didn't mention the target.  I'm
not aware of any option to do this, but the place to ask would be on
the mailing list for whatever assembler you are using.

Why can't you just move the calls to a different compilation unit?

Ian





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux