[PATCH] Change the way labels are propagated when comparing memory through libc functions

Lorenzo Martignoni martignlo at google.com
Fri Nov 29 06:37:21 PST 2013

  Right, we certainly do not want to complicate the build.

  The real problem is that we currently do not have any mechanism to tweak this, and without any such mechanism we cannot evaluate which approach works best.

  I think ideally we should have a conditional behaviour, but I'm not sure what it would be the best way to pick which behaviour to use (we already give some options at compile time, but the wrappers are part of the run-time and presumably not recompiled each time). Maybe we could build multiple libraries out of the same source file? Another option could be to allow to user to supply a custom implementation to replace the built-in one (through a weak symbol maybe?).

  Since we do not have any possibility to tweak the behaviour at the moment, I think for now we should go for the least conservative approach, that is, not propagate the labels unless really needed, to limit the risk of exhausting the set of labels. After all, the output of strcmp, even if it were data dependent on the input, would carry very minimal information about the input.

  I need to introduce a bunch of new wrappers (e.g., strrchr, strstr, memchr), but before I would like to come to an agreement :-)


More information about the llvm-commits mailing list