From: Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx> Date: Fri, 9 Jan 2009 08:42:09 -0600 (CST) > On Thu, 8 Jan 2009, David Miller wrote: > > > Otherwise, if overflow is possible, tranforming an array index > > comparison into a pointer comparison is no longer legal. > > This means that access to an object immediately before or after would wrap > around. If the object is not near 0 or near the end of the address space > then such a thing cannot occur. We have the ZERO page at address 0 so the > lower end is taken care and usually there are also special uses for very > high addresses. GCC, or any compiler, cannot know about such invariants. What it does know is that it can always transform comparisons between "i" and "max_i" into comparisons between '&array[i]' and '&array[max_i]' > The wrapping is mainly an issue if the percpu area is linked to very high > addresses but later the per cpu areas for the individual processors are > allocated on relatively low addresses. The address calculation of the > location of a percpu address for a particular cpu then occurs by > adding an offset that will wrap around zero. This is fine on x86. Anyways, the original reason for the RELOC_HIDE business is that GCC would do common subexpression elimination on the address computation. The percpu stuff was a calculation using a symbol address as some kind of base, and GCC took liberties with that (which were legal given the amount of information we (weren't) giving to it). I honestly forget the exact details, I'm sure Rusty could explain... -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
