This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/5741] Segfault in __libc_dlopen_mode ()
- From: "sjmunroe at us dot ibm dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 6 Feb 2008 17:31:37 -0000
- Subject: [Bug libc/5741] Segfault in __libc_dlopen_mode ()
- References: <20080206162655.5741.sjmunroe@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From sjmunroe at us dot ibm dot com 2008-02-06 17:31 -------
The solution is to replace the data cache block store with a data cache block
flush and strengthen the memory barrier from sync to sync followed by isync. The
new sequence in elf_machine_fixup_plt si:
plt->fd_aux = rel->fd_aux + offset;
plt->fd_toc = rel->fd_toc + offset;
PPC_DCBF (&plt->fd_toc);
PPC_ISYNC;
plt->fd_func = rel->fd_func + offset;
PPC_DCBST (&plt->fd_func);
PPC_ISYNC;
the data cache block flush forces the toc/aux update out to main store and
flushes the caches. the sync/isync sequence insure that the flush completes
before we proceed to the updating the function pointer. This will force any
other thread going through the call stubs to reload the cache (and stall the toc
load). This insures that the call stubs will always see the new toc pointer
before it sees the new function pointer.
This seems to resolve the problem (it has not reproduced after 300K iterations).
--
http://sourceware.org/bugzilla/show_bug.cgi?id=5741
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.