|
From: Julian S. <js...@ac...> - 2007-12-04 17:45:08
|
> > In short there's a conflict between optimising the hell out of stringops > > and having enough visibility for reliable debugging. Given the above > > constraints I don't see how you can have your cake and eat it. > > Unfortunately this conflicts with using Valgrind for other useful functions > like instruction trace. If you arbitrarily substitute your own string > functions, the trace is invalid. There is no conflict in the insn trace (etc) case. The intercepts I mention only apply to Memcheck, not to any of the other tools. J |
|
From: Julian S. <js...@ac...> - 2007-12-04 19:49:07
|
> > All these optimised, vectorised (effectively) string ops rely on two > > techniques: > > > > (1) using properties of carry-chain propagation in addition/subtraction > > so as find out whether any byte in a word is zero, and if so > > which one > > Do you mean the well know and widely use technique: [..] Yes. > note that in GLIBC the even the default generic implementation strlen.c > uses this trick. Yes. So Memcheck intercepts strlen et al in glibc. > Yup. On processors with wide registers and multiple Load/Store and FixPoint > units it would criminally negligent not to do this. Also you will be see a > lot more speculative loads in both hand tuned code and with GCC-4.3 > (Auto-vectorization and auto-parallelization). This applies to POWER > (Altivec) and x86(_64) (SSE4). In hand tuned code, perhaps. I would be surprised to see overruns in autovectorised code, since compilers tend only to vectorise loops for which the trip count is known at run time before the loop starts, and so generate a vector loop and a following fixup loop to handle any leftover iterations. So the vector loop doesn't overrun memory. > > * do not strip all symbol names off ld.so > > This is not really our call! You are going after LOCAL symbols which are > only needed for debug (not needed at run-time). The distros can strip > libraries to save space on the ISO images, so they do. The one concession > they make is to provide the debug-info images. In the end I simply arranged for Memcheck on ppc32/64-linux to check for the presence of the relevant symbols in ld.so, and crap out if they are not present, printing a message advising the user to install the debuginfo image. J |