|
From: Tom H. <to...@co...> - 2009-08-25 07:51:48
|
On 25/08/09 00:46, John Reiser wrote: > The next release of glibc (due in some weeks) implements a new symbol > type STT_IFUNC. This symbol type facilitates choosing at runtime a > software variant that may run faster/better/etc. on a specific processor. > The mechanism is: call the STT_IFUNC function; it returns the address > of the actual function which should be used on the current processor. > The caller typically puts the returned address of the optimized function > into the Program Linkage Table (PLT). The first uses include i686 and > x86_64 to choose among the serial/speculative/sseN implementations > of strlen, strcmp, etc. Are you saying that the dynamic linker takes care of all this magic itself without the client of the library having to know about it? ie that the first time you call the function the dynamic linker looks up the selection function and calls it and puts the returned address in the PLT instead of just looking up the symbol and putting that address in the PLT? > Because memcheck-3.5.0 does not understand STT_IFUNC, then memcheck > complains for the speculative overfetching of the default choice > for many str* subroutines. As seen on the alpha release of Fedora 12 > (due in the next 24 hrs), output looks like: What exactly are you suggesting that memcheck should do differently? Are you saying that we need to consider STT_IFUNC when scanning the symbol table and override the STT_IFUNC for strlen with our own version that returns a pointer to a naïve strlen that won't confuse memcheck? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |