Message ID | 87a75558n0.fsf@mid.deneb.enyo.de |
---|---|
State | Superseded |
Headers |
Received: (qmail 81187 invoked by alias); 26 Feb 2020 21:43:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 80102 invoked by uid 89); 26 Feb 2020 21:43:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:TLS1.2 X-HELO: albireo.enyo.de From: Florian Weimer <fw@deneb.enyo.de> To: Joseph Myers <joseph@codesourcery.com> Cc: Florian Weimer <fweimer@redhat.com>, <libc-alpha@sourceware.org>, <mjw@fedoraproject.org>, Patsy Griffin <patsy@redhat.com> Subject: Re: [PATCH] elf: Apply attribute_relro to pointers in elf/dl-minimal.c References: <87tv3d2x91.fsf@oldenburg2.str.redhat.com> <alpine.DEB.2.21.2002262121020.25531@digraph.polyomino.org.uk> Date: Wed, 26 Feb 2020 22:41:23 +0100 In-Reply-To: <alpine.DEB.2.21.2002262121020.25531@digraph.polyomino.org.uk> (Joseph Myers's message of "Wed, 26 Feb 2020 21:23:49 +0000") Message-ID: <87a75558n0.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain |
Commit Message
Florian Weimer
Feb. 26, 2020, 9:41 p.m. UTC
* Joseph Myers: > This change (commit 758599bc9dcc5764e862bd9e1613c5d1e6efc5d3) breaks the > build for alpha-linux-gnu with GCC and binutils mainline. I get a series > of errors of the form (this is in the "compilers" glibc build): > > /scratch/jmyers/glibc/many10/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/elf/librtld.os: > in function `calloc': > /scratch/jmyers/glibc/many10/src/glibc/elf/../include/rtld-malloc.h:44:(.text+0xd98): > relocation truncated to fit: GPREL16 against symbol `__rtld_calloc' > defined in .data.rel.ro section in > /scratch/jmyers/glibc/many10/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/elf/librtld.os > /scratch/jmyers/glibc/many10/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/elf/librtld.os: > in function `malloc': > /scratch/jmyers/glibc/many10/src/glibc/elf/../include/rtld-malloc.h:56:(.text+0x2978): > relocation truncated to fit: GPREL16 against symbol `__rtld_malloc' > defined in .data.rel.ro section in > /scratch/jmyers/glibc/many10/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/elf/librtld.os I don't know much about alpha unfortunately. Running this $ objdump -d --reloc /lib/ld-linux.so.2 | grep -E 'lda\s.*gp,' on a default build (not mainline, so successful) gives me what I assume are GP-relative load instructions ranging from 9ff4: 40 80 bd 23 lda gp,-32704(gp) to a040: f4 7f bd 23 lda gp,32756(gp) That seems to be rather close to the 64 KiB displacement that alpha apparently supports. This suggests me that we aren't hitting a bug as such, but that we were already rather near the limit before, and the additional PLT avoidance that the patch brought finally moved us across the limit. Would it be acceptable to switch from -fpic to -fPIC to fix this (if it addresses the issue)?
Comments
* Florian Weimer: > Would it be acceptable to switch from -fpic to -fPIC to fix this > (if it addresses the issue)? > > diff --git a/sysdeps/alpha/Makefile b/sysdeps/alpha/Makefile > index da52c1d4d1..baf5d480e5 100644 > --- a/sysdeps/alpha/Makefile > +++ b/sysdeps/alpha/Makefile > @@ -57,10 +57,6 @@ endif > # "current" rounding mode, and it's easiest to set this with all of them. > sysdep-CFLAGS += -mieee -mfp-rounding-mode=d > > -# libc.so requires about 16k for the small data area, which is well > -# below the 64k maximum. > -pic-ccflag = -fpic > - > # Software floating-point emulation. > > ifeq ($(subdir),soft-fp) alpha builds again with this patch. I also tried to remove the direct __ehdr_start reference in rtld.c: /* Starting from binutils-2.23, the linker will define the magic symbol __ehdr_start to point to our own ELF header if it is visible in a segment that also includes the phdrs. If that's not available, we use the old method that assumes the beginning of the file is part of the lowest-addressed PT_LOAD segment. */ #ifdef HAVE_EHDR_START extern const ElfW(Ehdr) __ehdr_start __attribute__ ((visibility ("hidden"))); rtld_ehdr = &__ehdr_start; #else rtld_ehdr = (void *) GL(dl_rtld_map).l_map_start; #endif It looks like something that could be problematic to represent due to section ordering. But getting rid of that (either by reverting to the old mechanism or introducing a level of indirection) is not sufficient to address the build failure. I'd prefer to use -fPIC for now. If someone finds a way to make -fpic work, than we can of course consider making that change.
* Florian Weimer: > I don't know much about alpha unfortunately. Running this > > $ objdump -d --reloc /lib/ld-linux.so.2 | grep -E 'lda\s.*gp,' > > on a default build (not mainline, so successful) gives me what I > assume are GP-relative load instructions ranging from > > 9ff4: 40 80 bd 23 lda gp,-32704(gp) > > to > > a040: f4 7f bd 23 lda gp,32756(gp) > > That seems to be rather close to the 64 KiB displacement that alpha > apparently supports. The above isn't correct. These instructions are half of the gp register setup. There are more bits available in a different instruction. I still beleive this is a current toolchain limitation. I tried linking with -Wl,--no-relax and also skipping the librtld.os stage, but this didn't fix this. I think we have no choice but to drop -fpic at this point and use -fPIC.
diff --git a/sysdeps/alpha/Makefile b/sysdeps/alpha/Makefile index da52c1d4d1..baf5d480e5 100644 --- a/sysdeps/alpha/Makefile +++ b/sysdeps/alpha/Makefile @@ -57,10 +57,6 @@ endif # "current" rounding mode, and it's easiest to set this with all of them. sysdep-CFLAGS += -mieee -mfp-rounding-mode=d -# libc.so requires about 16k for the small data area, which is well -# below the 64k maximum. -pic-ccflag = -fpic - # Software floating-point emulation. ifeq ($(subdir),soft-fp)