FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-17-2010, 03:03 PM
John Reiser
 
Default work-around: the glibc adobe flash incompatibility

> For those who do not know it yet, recent Fedora glibc updates include
> an optimized memcpy (which gets used on some processors) which breaks the
> 64 bit adobe flash plugin.

For right now (the immediate present) a work-around is to use the 'memmove'
subroutine as the resolution of any reference to the symbol 'memcpy'.
The quick-and-dirty way to do this, is to overwrite with "memmove"
the unused {DT_NULL}.d_un field [which is 8 bytes on x86_64] of the
PT_DYNAMIC section, then change the {'memcpy'}.st_name field of the
DT_SYMTAB to designate the overwritten substring. The PT_DYNAMIC
segment appears after the DT_STRTAB, so the {'memcpy'}.st_name value
[now {'memmove'}.st_name] will be some much larger index than previously.

Another way might be to re-order the DT_NEEDED entries in the PT_DYNAMIC
segment so that "ld-linux.so.2" comes first, lop off the first DT_NEEDED
by increasing the address and decreasing the size by 2*sizeof(void *),
overwriting the "ld-linux.so.2" in the DT_STRTAB with "memmove", then
setting {'memcpy'}.st_name. ld-linux.so.2 will be there anyway.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-17-2010, 03:25 PM
Chris Adams
 
Default work-around: the glibc adobe flash incompatibility

Once upon a time, John Reiser <jreiser@bitwagon.com> said:
> For right now (the immediate present) a work-around is to use the 'memmove'
> subroutine as the resolution of any reference to the symbol 'memcpy'.
> The quick-and-dirty way to do this

It would probably be easier to use an LD_PRELOAD to load a wrapper to
change memcpy() with overlaps to memmove(). This would obviously slow
down all memcpy() calls, but maybe it could just be used for Flash (or
at least just for plugins). Something like (untested):


/* Library preload to replacing overlapping memcpy() with memmove()
*
* Compile with:
* gcc -O2 -ldl -fpic -shared -o preload-memcpy.so preload-memcpy.c
* Use like
* LD_PRELOAD=/path/to/preload-memcpy.so; export LD_PRELOAD
* <some command>
*/

#define _GNU_SOURCE
#include <string.h>
#include <dlfcn.h>
#include <assert.h>

static void * (*real_memcpy) (void *dest, const void *src, size_t n);
void *memcpy (void *dest, const void *src, size_t n)
{
char *d = (char *) dest;
char *s = (char *) src;

if (((d < s) && ((d + n - 1) >= s)) ||
((s < d) && ((s + n - 1) >= d)))
return memmove (dest, src, n);
if (! real_memcpy)
assert (real_memcpy = dlsym (RTLD_NEXT, "memcpy"));
return real_memcpy (dest, src, n);
}


--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-17-2010, 04:23 PM
drago01
 
Default work-around: the glibc adobe flash incompatibility

On Wed, Nov 17, 2010 at 5:03 PM, John Reiser <jreiser@bitwagon.com> wrote:
>> For those who do not know it yet, recent Fedora glibc updates include
>> an optimized memcpy (which gets used on some processors) which breaks the
>> 64 bit adobe flash plugin.
>
> For right now (the immediate present) a work-around is to use the 'memmove'
> subroutine as the resolution of any reference to the symbol 'memcpy'.

Ray has written a script to do exactly that
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c94
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org