| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Aug 2006 09:30:21 +0800 From: "Dong Feng" <middle.fengdong@...il.com> To: "Paul Mackerras" <paulus@...ba.org>, ak@...e.de Cc: "Christoph Lameter" <clameter@....com>, linux-kernel@...r.kernel.org Subject: Re: Unnecessary Relocation Hiding? Sorry for perhaps extending the specific question to a more generic one. In which cases shall we, in current or future development, prevent gcc from knowing a pointer-addition in the way RELOC_HIDE? And in what cases shall we just write pure C point addition? After all, we are writing an OS in C not in pure assembly, so I am just trying to learn some generial rules to mimize the raw assembly in development. Feng,Dong 2006/8/25, Paul Mackerras <paulus@...ba.org>: > Christoph Lameter writes: > > No, RELOC_HIDE came from ppc originally. The reason for it is that > gcc assumes that if you add something on to the address of a symbol, > the resulting address is still inside the bounds of the symbol, and do > optimizations based on that. The RELOC_HIDE macro is designed to > prevent gcc knowing that the resulting pointer is obtained by adding > an offset to the address of a symbol. As far as gcc knows, the > resulting pointer could point to anything. > > It has nothing to do with linker relocations. > > Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists