On Tue, 27 Jun 2006, Jason Thorpe wrote:

> ...and what happens if you open-code the copy in store_ptr() instead of 
> calling memcpy() (keeping store_ptr() as an inline).

Yes, this will work... ...until we update gcc to a newer version that
is smart enough to see that it is a memcpy in disguise (actually, I'm
a bit surprised that it does not see that already...)

All these hacks to fool the compiler not to optimize are really too
unstable to use -- each new version of gcc contain better optimizations
that risk see through the obfuscations and thus introduce hard-to-find
bugs.


> Seems that THAT would be the least-invasive change to make.

The problem with Simon's patch is not that it is intrusive -- the
problem is that it is not intrusive enough... :)  It still contains
places where unaligned pointers are stored in pointer types that
need alignment [*] (see my old post [**] for some standard lawyering
about the issue), and I'm certain that future compilers will be
able to determine that even the newly introduced void *wherev must
be aligned... [***]

    /Krister


[*] @@ -133,7 +134,8 @@ _rtld_relocate_nonplt_self(Elf_Dyn *dynp

         rellim = (const Elf_Rel *)((caddr_t)rel + relsz);
         for (; rel < rellim; rel++) {
-               where = (Elf_Addr *)(relocbase + rel->r_offset);
+               wherev = (void *)(relocbase + rel->r_offset);
+               where = wherev;
                       ^-- this is invalid unless wherev is aligned,
                           i.e. the compiler may assume wherev is aligned.

[**] http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html

[***] gcc-current does already contain the kind of reasoning from [*]
for at least some other properties (I'm planning to update [**] with some
examples how this may break our code before we import gcc next time... :-)