This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [patch] handle unaligned arm abs relocs
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-ports at sourceware dot org
- Date: Mon, 19 Dec 2011 17:45:30 +0000 (UTC)
- Subject: Re: [patch] handle unaligned arm abs relocs
- References: <201112121920.17908.vapier@gentoo.org>
On Mon, 12 Dec 2011, Mike Frysinger wrote:
> + /* Support relocations on mis-aligned offsets. */
> + memcpy (&reloc_value, reloc_addr_arg, sizeof (reloc_value));
> + reloc_value += value;
> + memcpy (reloc_addr_arg, &reloc_value, sizeof (reloc_value));
It seems from the discussion that it would be useful to see exactly what
code ends up getting generated for these memcpy calls. Is it a function
call or inlined? What about all the other memcpy calls in the dynamic
linker? For calls to memcpy that really are function calls, do they end
up going through the PLT, or do they end up as direct calls to the copy of
memcpy in the dynamic linker (given that it's linked with a version script
that hides memcpy along with all the other libc functions it uses, so it
shouldn't be necessary for calls to go through the PLT)?
(If it ends up as a direct call, care might still be needed if ARM memcpy
ends up using STT_GNU_IFUNC in future - I think some architectures disable
IFUNC versions of string functions in the dynamic linker, though that may
be for code size reasons - but that's something to watch out for in future
rather than needing addressing now.)
--
Joseph S. Myers
joseph@codesourcery.com