On Fri, May 05, 2017 at 12:32:03PM -0700, Evgeny Stupachenko wrote: > Hi Michael, > > On Fri, May 5, 2017 at 11:45 AM, Michael Meissner > <meiss...@linux.vnet.ibm.com> wrote: > > This message is separated from the question about moving code, as it is a > > questions about the functionality of target_clone support. > > > > Right now it looks like target_clone only generates the ifunc handler if > > there > > is a call to the function in the object file. It does not generate the > > ifunc > > handler if there is no call. > > > > For the default function, it generates the normal name. This means that any > > function that calls the function from a different object module will only > > get > > the standard function. From a library and user perspective, I think this is > > wrong. Instead the default function should be generated with a different > > name, > > and the ifunc function should list the standard name. Then you don't have > > to > > change all of the other calls in the object file, the normal ifunc handling > > will handle it. It also means you can more easily put this function in a > > library and automatically call the appropriate version. > > I think library issue could be resolved using special headers. You can > look into GLIBC, there should be similar technique. > When you call resolver from initial (default) function, you make an > assumption that ifunc is supported.
Yes, ifunc should be required before you even consider using target_clone. What I'm trying to do is make it easier for people to add target clones to their code, but not having to go through using special headers or other gunk. I want them to be able to add just the target clone line, and everything will work. That means in the current case, the default case should be renamed to <function>.default, and what is <function>.ifunc should become <function>. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
