* ld --wrap option
@ 2013-12-12 18:29 Greg Hopkins
2013-12-12 22:48 ` Ian Lance Taylor
2013-12-13 1:03 ` Ángel González
0 siblings, 2 replies; 6+ messages in thread
From: Greg Hopkins @ 2013-12-12 18:29 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ld --wrap option
2013-12-12 18:29 ld --wrap option Greg Hopkins
@ 2013-12-12 22:48 ` Ian Lance Taylor
2013-12-12 23:00 ` Greg Hopkins
2013-12-13 1:03 ` Ángel González
1 sibling, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2013-12-12 22:48 UTC (permalink / raw)
To: Greg Hopkins; +Cc: gcc-help
On Thu, Dec 12, 2013 at 10:28 AM, Greg Hopkins <Greg.Hopkins@csr.com> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: ld --wrap option
2013-12-12 22:48 ` Ian Lance Taylor
@ 2013-12-12 23:00 ` Greg Hopkins
0 siblings, 0 replies; 6+ messages in thread
From: Greg Hopkins @ 2013-12-12 23:00 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help, Richard Brewin
Thank you, Ian. The toolchain is an internally-developed, gcc-based, one, tied to a proprietary DSP ASIC.
As for moving the calls, I've been trying to avoid such brute-force methods, relying on the power of the toolchain options, some standard; some more esoteric. As a last resort, I may have to go the brute force way.
Regards,
Greg
-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com]
Sent: Thursday, December 12, 2013 3:49 PM
To: Greg Hopkins
Cc: gcc-help@gcc.gnu.org
Subject: Re: ld --wrap option
On Thu, Dec 12, 2013 at 10:28 AM, Greg Hopkins <Greg.Hopkins@csr.com> 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
To report this email as spam click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ld --wrap option
2013-12-12 18:29 ld --wrap option Greg Hopkins
2013-12-12 22:48 ` Ian Lance Taylor
@ 2013-12-13 1:03 ` Ángel González
2013-12-13 12:51 ` Greg Hopkins
1 sibling, 1 reply; 6+ messages in thread
From: Ángel González @ 2013-12-13 1:03 UTC (permalink / raw)
To: Greg Hopkins; +Cc: gcc-help
On 12/12/13 19:28, Greg Hopkins wrote:
> Resending due to urgent need. Please help if you can. Thank you.
>
> Regards,
> Greg
If you are trying to wrap the funcion from the same file where it's
defined, there are a few easy tricks to wrap it, from the original
function to #defining the name to the wrapper.
Although the best solution coulb be to move it to a separate file.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: ld --wrap option
2013-12-13 1:03 ` Ángel González
@ 2013-12-13 12:51 ` Greg Hopkins
0 siblings, 0 replies; 6+ messages in thread
From: Greg Hopkins @ 2013-12-13 12:51 UTC (permalink / raw)
To: Ángel González; +Cc: gcc-help
Thanks, Ángel. I can see how a "#define fn __wrap_fn", coupled with a "#undef fn" at fn definition would do the trick.
Regards,
Greg
-----Original Message-----
From: Ángel González [mailto:keisial@gmail.com]
Sent: Thursday, December 12, 2013 6:03 PM
To: Greg Hopkins
Cc: gcc-help@gcc.gnu.org
Subject: Re: ld --wrap option
On 12/12/13 19:28, Greg Hopkins wrote:
> Resending due to urgent need. Please help if you can. Thank you.
>
> Regards,
> Greg
If you are trying to wrap the funcion from the same file where it's defined, there are a few easy tricks to wrap it, from the original function to #defining the name to the wrapper.
Although the best solution coulb be to move it to a separate file.
To report this email as spam click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* ld --wrap option
@ 2013-12-09 23:53 Greg Hopkins
0 siblings, 0 replies; 6+ messages in thread
From: Greg Hopkins @ 2013-12-09 23:53 UTC (permalink / raw)
To: gcc-help
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-12-13 12:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-12 18:29 ld --wrap option Greg Hopkins
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
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).