don't assume reloc_addr passed to elf_machine_rel* is aligned
Alexandre Oliva
aoliva@redhat.com
Wed Jun 25 00:53:00 GMT 2003
On Jun 24, 2003, Roland McGrath <roland@redhat.com> wrote:
> I took another look at this patch. While I think it is probably ok, it
> seems cleaner not to use the trailing _ variable name and temporary
> variable--instead just have each store use an explicit cast
I find explicit casts ugly, and I don't know whether every
architecture I touched may have unaligned relocations. My patch was a
syntactical-only change. I was leaving it up to each arch's
maintainer to figure out whether there were cases in which a compiler
might be assuming too much from the implied alignment of the pointer,
and adjust the code correspondingly. It didn't mean to fix any bug in
any architecture, other than letting mips*-linux-gnu build again
because it must handle unaligned relocations properly.
> Or is that danger removed
> by going through a void * stage?
The danger is there, and going through a void* stage doesn't remove it
at all. If the compiler can ever tell that the pointer was cast to a
pointer that requires more alignment, even if it is cast back, the
compiler can still assume stricter alignment than warranted by a void*
without any additional information.
> Anyway, it's a bit unsightly and it's not so hard to modify each
> machine's file that it can't be made prettier.
But then, the risk of breaking something would also increase. I wrote
the patch the way I did such that it would be trivial to see it didn't
introduce any functional changes. I can't possibly go through testing
a dozen platforms. I don't really care about changing them all; I'd
much rather go with the mips-specific change for the mips-specific
need. I'm just tired of this whole thing :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
More information about the Libc-alpha
mailing list