Bug 15605 - gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC
Summary: gcc-4.8 + tree-loop-distribute-patterns breaks is unsafe for GLIBC
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: hurd (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-11 20:01 IST by Adhemerval Zanella Netto
Modified: 2016-10-20 19:23 IST (History)
8 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adhemerval Zanella Netto 2013-06-11 20:01:15 IST
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).
Comment 1 Adhemerval Zanella Netto 2013-06-12 17:12:32 IST
The spurious memset/memmove PLT generations was fixed by commit 6a97b62a5b4f18aea849d6f4d8de58d1469d2521.
Comment 2 Thomas Schwinge 2013-10-10 06:06:12 IST
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?
Comment 3 joseph@codesourcery.com 2013-10-10 11:36:39 IST
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?
Comment 4 Thomas Schwinge 2013-10-10 12:08:19 IST
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?
Comment 5 Roland McGrath 2013-10-23 22:39:16 IST
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.)
Comment 6 cvs-commit@gcc.gnu.org 2014-01-20 19:11:49 IST
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(-)
Comment 7 cvs-commit@gcc.gnu.org 2014-01-20 19:15:07 IST
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(-)
Comment 8 philippe.gislard 2015-02-25 18:51:11 IST
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.
Comment 9 philippe.gislard 2015-02-25 19:01:51 IST
(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
Comment 10 Adhemerval Zanella 2016-10-20 19:23:37 IST
OK I will change it to component to 'hurd' and let them have a better idea on how to exactly handle this correctly.