public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Greg Hopkins <Greg.Hopkins@csr.com>
To: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: ld --wrap option
Date: Thu, 12 Dec 2013 18:29:00 -0000	[thread overview]
Message-ID: <1875ABFC44A4C049BF86786B1EE9A6DD179BD853@SUNAMSEXM01.AMERICAS.ROOT.PRI> (raw)

Resending due to urgent need.  Please help if you can.  Thank you.

Regards,
Greg

-----Original Message-----
From: Greg Hopkins 
Sent: Monday, December 09, 2013 4:53 PM
To: 'gcc-help@gcc.gnu.org'
Subject: ld --wrap option

Hi,

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.

Thank you,
Greg



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog

             reply	other threads:[~2013-12-12 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12 18:29 Greg Hopkins [this message]
2013-12-12 22:48 ` Ian Lance Taylor
2013-12-12 23:00   ` Greg Hopkins
2013-12-13  1:03 ` Ángel González
2013-12-13 12:51   ` Greg Hopkins
  -- strict thread matches above, loose matches on Subject: below --
2013-12-09 23:53 Greg Hopkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1875ABFC44A4C049BF86786B1EE9A6DD179BD853@SUNAMSEXM01.AMERICAS.ROOT.PRI \
    --to=greg.hopkins@csr.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).