This looks like a potentially handy feature, and the architecture seems
fairly straight-forward. However, I'm not sure it qualifies for
self-review. (Although the bar for self review seems to be moving
somewhat...) If only because it introduces new interfaces and behavior
for consumers.
I'd suggest that this maybe should be a fast-track instead of self
review, unless there is some particular rush to get this case through?
Please consider promoting it to a fast track. In any case, I'll happily
give it a +1.
Btw, you failed to specify a release binding. Is this patch or minor
(or something else)? (It looks like this could be Patch binding fairly
easily...)
- Garrett
Ali Bahrami wrote:
> I am sponsoring the following self-reviewed case for myself.
>
> It adds a new option (-z wrap=symbol) to the Solaris link-editor (ld)
> along with two synonyms: -wrap=symbol and --wrap=symbol.
>
> I believe it qualifies for self review:
>
> - This is a GNU familiarity case --- the GNU ld used by Linux accepts
> the -wrap/--wrap options and it is used by software of
> importance to
> Solaris (Xorg).
>
> - We have established precedent for providing GNU ld options to ease
> building of open source software on our platform. One example is:
>
> PSARC 2008/583 add gld options to ld(1)
>
> - There are no backward compatibility issues with the proposed
> syntax,
> and the form of the syntax does not break new ground.
>
> The wrap option tells the link-editor to rename function references
> in a systematic way that allows the user to link "wrapper" functions
> against already compiled code. The user of this feature supplies the
> wrapper functions. This feature will be integrated as:
>
> 6850768 ld option to autogenerate wrappers/interposers similar to
> GNU ld --wrap
>
> Documentation for the original GNU ld feature can be found at:
>
>
> http://sourceware.org/binutils/docs-2.19/ld/Options.html#index-g_t_002d_002dwrap-249
>
>
>
> Diffs for the changes to the proposed new ld(1) manpage are shown below.
>
> -----
>
> Release Binding: Patch/Micro
>
> New ld options:
> -z wrap Committed
> -wrap Committed
> --wrap Committed
>
> -----
>
> *** ld.orig Mon Aug 24 14:38:24 2009
> --- ld.new Tue Sep 15 13:28:59 2009
> ***************
> *** 30,36 ****
> [-z preinitarray=function] [-z redlocsym] [-z relaxreloc]
> [-z rescan-now] [-z recan] [-z rescan-start ... -z rescan-end]]
> [-z target=sparc|x86] [-z text | textwarn | textoff]
> ! [-z verbose] filename...
>
>
> DESCRIPTION
> --- 30,36 ----
> [-z preinitarray=function] [-z redlocsym] [-z relaxreloc]
> [-z rescan-now] [-z recan] [-z rescan-start ... -z rescan-end]]
> [-z target=sparc|x86] [-z text | textwarn | textoff]
> ! [-z verbose] [-z wrap=symbol] filename...
>
>
> DESCRIPTION
> ***************
> *** 1114,1119 ****
> --- 1114,1152 ----
> are deemed too noisy to be generated by default.
>
>
> + -z wrap=symbol
> + -wrap=symbol
> + --wrap=symbol
> +
> + Rename undefined references to symbol in order to allow
> wrapper
> + code to be linked into the output object without having to
> modify
> + source code. When -z wrap is specified, all undefined
> references
> + to symbol are modified to reference __wrap_symbol, and all
> + references to __real_symbol are modified to reference
> symbol. The
> + user is expected to provide an object containing the
> __wrap_symbol
> + function. This wrapper function can call __real_symbol in
> order to
> + reference the actual function being wrapped.
> +
> + The following is an example of a wrapper for the malloc()
> function:
> +
> + void *
> + __wrap_malloc (size_t c)
> + {
> + printf ("malloc called with %zu\n", c);
> + return __real_malloc (c);
> + }
> +
> + If you link other code with this file using -z wrap=malloc to
> + compile all the objects, then all calls to malloc will call
> the
> + function __wrap_malloc instead. The call to __real_malloc in
> + __wrap_malloc will call the real malloc function.
> +
> + The real and wrapped functions should be maintained in
> separate
> + source files. Otherwise, the compiler or assembler may resolve
> + the call instead of leaving that operation for the link-editor
> + to carry out, and prevent the wrap from occurring.
> +
> +
> ENVIRONMENT VARIABLES
> LD_ALTEXEC
>
