On 24 December 2011 12:14, Bart Van Assche wrote:
>
> Would it be technically possible to implement a binary patching
> approach in a user space shared library similar to the binary patching
> technique used in the kprobe implementation in the Linux kernel ?
>
> For more information, see also
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Documentation/kprobes.txt.
I don't know, but honestly, IMHO the use case of race detectors is not
important enough to bother. Recompiling the required objects and
linking to them is just not that difficult.
I think the guideline of "you don't pay for what you don't use" must
apply to any changes made for race detection in the library. While
runtime cost is the most important, maintenance cost also matters. We
accepted the patch adding the macros to the library sources because
they add no cost for most users and allow those who care to use race
detectors (albeit with some minor hassle of recompiling some source
files). You are now trying to turn something where we said "sure, why
not, let's include it" into something far more intrusive that is not
stritly necessary (just more convenient) and of no value for most
users.
I would support adding a configure option such as
--enable-libstdcxx-race-detection={drd,tsan,...} which automatically
built and installed a variant of the library using the specified race
detector, similar to the --enable-libstdcxx-debug option which builds
an unoptimized, unstripped libstdc++.so and places it in
${libdir}/debug/
One of the values for the option could be "user" which would make the
relevant libstdc++ files include a user-defined header, which could
define the macros to whatever you want, including calling a global
function pointer which may or may not be set.
