From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27412 invoked by alias); 12 Dec 2013 18:29:12 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 27397 invoked by uid 89); 12 Dec 2013 18:29:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: cluster-d.mailcontrol.com Received: from cluster-d.mailcontrol.com (HELO cluster-d.mailcontrol.com) (85.115.60.190) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 12 Dec 2013 18:29:09 +0000 Received: from sunapppus01.americas.root.pri (nse-zco.zoran.com [67.98.200.2]) by rly49d.srv.mailcontrol.com (MailControl) with ESMTP id rBCIT3xI028079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 12 Dec 2013 18:29:04 GMT Received: from SJOAMSEXC01.AMERICAS.ROOT.PRI ([10.110.12.85]) by sunapppus01.americas.root.pri (PGP Universal service); Thu, 12 Dec 2013 10:29:04 -0800 X-PGP-Universal: processed; by sunapppus01.americas.root.pri on Thu, 12 Dec 2013 10:29:04 -0800 Received: from SUNAMSEXM01.AMERICAS.ROOT.PRI ([fe80::8c6d:f372:6dee:cc4b]) by SJOAMSEXC01.AMERICAS.ROOT.PRI ([10.110.12.85]) with mapi id 14.03.0158.001; Thu, 12 Dec 2013 10:28:52 -0800 From: Greg Hopkins To: "gcc-help@gcc.gnu.org" Subject: ld --wrap option Date: Thu, 12 Dec 2013 18:29:00 -0000 Message-ID: <1875ABFC44A4C049BF86786B1EE9A6DD179BD853@SUNAMSEXM01.AMERICAS.ROOT.PRI> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-12/txt/msg00090.txt.bz2 Resending due to urgent need. Please help if you can. Thank you. Regards, Greg -----Original Message----- From: Greg Hopkins=20 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 ca= lled from within the modules in which they (the real) functions are defined= . An ojbdump of the final executable disassembly shows all calls from outsi= de of the defining module correctly resolve to __wrap_function_name, (which= is currently written to then call __real_function_name to complete the exe= cution threads.) However, for any particular function_name, all calls to f= unction_name from within its defining module go directly to the target, "re= al", 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 bypas= sing calls to correctly link to the wrapper functions? I've tried --undefin= ed=3Dfunction_name; that didn't work; the intramodules direct calls still o= ccurred. I also tried --defsym=3Dfunction_name=3D__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, Cambr= idge 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