GCC 4.8 now enables -ftree-loop-distribute-patterns at -O3 by default. This optimization option may transform loops into memset/memmove call (http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Optimize-Options.html#Optimize-Options) and without proper handling this may generate unexpected PLT calls on GLIBC builds. Carlos O'Donell raised his concerns (http://sourceware.org/ml/libc-alpha/2013-02/msg00299.html), there is also reports on recursive calls building the default memset/memmove implementations (http://sourceware.org/ml/libc-alpha/2013-05/msg00731.html), and tt was observed some PLT issues on PPC32/PPC64 builds as well (http://sourceware.org/ml/libc-alpha/2013-04/msg00131.html).
The spurious memset/memmove PLT generations was fixed by commit 6a97b62a5b4f18aea849d6f4d8de58d1469d2521.
This commit breaks the build in --disable-hidden-plt configurations, where there are no __GI_memmove and __GI_memset symbols. What to do in this case?
On Thu, 10 Oct 2013, tschwinge at sourceware dot org wrote: > This commit breaks the build in --disable-hidden-plt configurations, where > there are no __GI_memmove and __GI_memset symbols. What to do in this case? Remove the undocumented --disable-hidden-plt configure option? What purpose does it serve?
In sysdeps/mach/hurd/configure (configure.in), the Hurd hard-codes NO_HIDDEN citing »the need for PLT calls in ld.so«. I think I have some rough idea what this is about (as soon as available, use the "full" implementations of functions in libc when invoked from ld.so instead of the "reduced" implementations residing in ld.so itself?), but will have to look into it in more detail, or perhaps Roland can clarify?
Yes, in the Hurd it's crucial that calls like __mmap be the libc ones instead of the rtld-local ones after the bootstrap phase, when the dynamic linker is being used for dlopen and the like. Probably the right thing to do is not to disable PLT avoidance altogether, but to have the rtld_hidden_* macros disabled in the Hurd configuration. (Actually it would really be ideal just to select the exact set that should use PLT calls for the Hurd. But we could start with disabling it for rtld altogether and then seeing how many PLT entries we get.)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via 4959e284ca9c4ee749e1fe4b95ce682dee110a27 (commit) from d98720e07f67fbeec00f9e1347840404240d3c48 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4959e284ca9c4ee749e1fe4b95ce682dee110a27 commit 4959e284ca9c4ee749e1fe4b95ce682dee110a27 Author: H.J. Lu <hjl.tools@gmail.com> Date: Mon Jan 20 11:05:22 2014 -0800 Include generic symbol-hacks.h for x32 In BZ #15605 fix with addding memset/memmove alias in symbol-hacks.h, x32 symbol-hacks.h change was missing. Fixed by including <sysdeps/generic/symbol-hacks.h> in x32 symbol-hacks.h. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 5 +++++ sysdeps/x86_64/x32/symbol-hacks.h | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, release/2.18/master has been updated via 2a8396b962b8c57a2581023b62766a3ac44c3ba4 (commit) from 0553c6642be2cdf6bac776fac5fd50164cb28709 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2a8396b962b8c57a2581023b62766a3ac44c3ba4 commit 2a8396b962b8c57a2581023b62766a3ac44c3ba4 Author: H.J. Lu <hjl.tools@gmail.com> Date: Mon Jan 20 11:05:22 2014 -0800 Include generic symbol-hacks.h for x32 In BZ #15605 fix with addding memset/memmove alias in symbol-hacks.h, x32 symbol-hacks.h change was missing. Fixed by including <sysdeps/generic/symbol-hacks.h> in x32 symbol-hacks.h. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 5 +++++ sysdeps/x86_64/x32/symbol-hacks.h | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-)
Hi, I'm using gcc 4.9.1, and I have and issue when reimplementing memset that is quite similar: loop inside memset is transformed into recursive call to memset I noticed that when compiling with -fno-tree-loop-distribute-patterns has no impact but with -fno-tree-ch the issue disappear. Can someone tell me if it is related to this bug and if possible, what's happening exactly and if there is a better way to handle this ? Thanks.
(In reply to philippe.gislard from comment #8) > Hi, > > I'm using gcc 4.9.1, and I have and issue when reimplementing memset that is > quite similar: > loop inside memset is transformed into recursive call to memset > > I noticed that when compiling with -fno-tree-loop-distribute-patterns has no > impact but with -fno-tree-ch the issue disappear. > Can someone tell me if it is related to this bug and if possible, what's > happening exactly and if there is a better way to handle this ? > > Thanks. My bad: -fno-tree-loop-distribute-patterns DOES workaround this issue
OK I will change it to component to 'hurd' and let them have a better idea on how to exactly handle this correctly.