From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] ia64: fix dl-sysdep miscompilation on gcc-10
Date: Wed, 20 May 2020 16:45:03 -0300 [thread overview]
Message-ID: <9c8a4db6-53d2-6d32-b7af-2322001572af@linaro.org> (raw)
In-Reply-To: <20200516135332.3969575-1-slyich@gmail.com>
On 16/05/2020 10:53, slyich--- via Libc-alpha wrote:
> From: Sergei Trofimovich <slyfox@gentoo.org>
>
> gcc-10 enabled -fno-common by default. This caused glibc link failure:
>
> ```
> $ ia64-unknown-linux-gnu-gcc -pipe -O2 -nostdlib -nostartfiles \
> -static -o .../elf/sln ...
> libc.a(dl-support.o): in function `setup_vdso':
> glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322):
> relocation truncated to fit: GPREL22 against `.text'
> collect2: error: ld returned 1 exit status
> ```
I can't reproduce it with master (b6ad64b907ab00) with GCC 10.1.1 20200520.
(built using build-many-glibcs.py). I tried to explicit use -fno-common on
CFLAGS. Are you sing a non default compiler option?
>
> The difference between gcc-9 and gcc-10 is the way relocation is
> generated for ia64-specific symbol '_dl_sysinfo_break', defined as:
>
> ```c
> 32 #ifndef __ASSEMBLER__
> 33 /* Don't declare this as a function---we want it's entry-point, not
> 34 it's function descriptor... */
> 35 extern int _dl_sysinfo_break attribute_hidden;
> 36 # define DL_SYSINFO_DEFAULT ((uintptr_t) &_dl_sysinfo_break)
> 37 # define DL_SYSINFO_IMPLEMENTATION \
> 38 asm (".text\n\t" \
> 39 ".hidden _dl_sysinfo_break\n\t" \
> 40 ".proc _dl_sysinfo_break\n\t" \
> ```
>
> Note: it's declared as ".sdata" (defined nearby GOT) but assumed
> to be defined in ".text" as it's really a direct function address.
>
> As a result generated relocation changed from:
>
> from `GPREL64I`:
>
> ```
> 1390: 05 00 84 1e 98 11 [MLX] st8 [r15]=r33
> 1391: GPREL64I .text
> 1396: 00 00 00 00 00 e0 movl r15=0x0;;
> 139c: 01 00 00 60
> 13a0: 0b 78 04 1e 00 20 [MMI] add r15=r1,r15;;
> ```
>
> to `GPREL22`:
>
> ```
> if (GLRO(dl_sysinfo) == DL_SYSINFO_DEFAULT)
>
> 1320: 0b 80 00 1c 18 10 [MMI] ld8 r16=[r14];;
> 1322: GPREL22 .text
> 1326: 00 08 3d 30 23 e0 st8 [r15]=r33
> 132c: 01 08 00 90 addl r15=0,r1;;
> ```
>
> This change explicitly declares symbol to be in ".text" section.
> That allows gcc to generate far relocations.
>
> Regression tested on glibc-master and gcc-10.1.0 on rx3600.
The rationale is sound, but the trick to define a function pointer a
data variable on text sections seems hacky and fragile. I still think
it could be a fix, but I think we should refactor and simplify
the over-enginnering of NEED_DL_SYSINFO/USE_DL_SYSINFO.
>
> Bug: https://bugs.gentoo.org/723268
> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
> ---
> sysdeps/unix/sysv/linux/ia64/dl-sysdep.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/unix/sysv/linux/ia64/dl-sysdep.h b/sysdeps/unix/sysv/linux/ia64/dl-sysdep.h
> index 78fa6dd2c9..e526e02ff4 100644
> --- a/sysdeps/unix/sysv/linux/ia64/dl-sysdep.h
> +++ b/sysdeps/unix/sysv/linux/ia64/dl-sysdep.h
> @@ -32,7 +32,9 @@
> #ifndef __ASSEMBLER__
> /* Don't declare this as a function---we want it's entry-point, not
> it's function descriptor... */
> -extern int _dl_sysinfo_break attribute_hidden;
> +/* Use section ".text" to force far GPREL64 relocation instead of
> + GPREL22 . */
> +extern int _dl_sysinfo_break attribute_hidden __attribute__((section(".text")));
> # define DL_SYSINFO_DEFAULT ((uintptr_t) &_dl_sysinfo_break)
> # define DL_SYSINFO_IMPLEMENTATION \
> asm (".text\n\t" \
>
next prev parent reply other threads:[~2020-05-20 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-16 13:53 slyich
2020-05-20 19:45 ` Adhemerval Zanella [this message]
2020-05-31 19:34 ` Sergei Trofimovich
2020-05-31 21:40 ` Sergei Trofimovich
2020-06-05 18:44 ` Adhemerval Zanella
2020-06-05 21:31 ` Sergei Trofimovich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c8a4db6-53d2-6d32-b7af-2322001572af@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).