Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 723268 - =sys-libs/glibc-2.31-r3 fails to build on ia64's gcc-10: relocation truncated to fit: GPREL22 against `.text'
Summary: =sys-libs/glibc-2.31-r3 fails to build on ia64's gcc-10: relocation truncated...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Toolchain Maintainers
URL: https://sourceware.org/pipermail/libc...
Whiteboard:
Keywords:
Depends on:
Blocks: -fno-common glibc-2.31
  Show dependency tree
 
Reported: 2020-05-15 17:50 UTC by Sergei Trofimovich
Modified: 2020-10-18 15:01 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
glibc-2.31-ia64-fno-common.patch (glibc-2.31-ia64-fno-common.patch,579 bytes, patch)
2020-05-16 11:44 UTC, Sergei Trofimovich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich gentoo-dev 2020-05-15 17:50:43 UTC
Failure snippet:

"""
guppy /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl # LANG=C ia64-unknown-linux-gnu-gcc  -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed -nostdlib -nostartfiles -static -o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/sln     /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crt1.o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crti.o `ia64-unknown-linux-gnu-gcc  -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed  --print-file-name=crtbegin.o` /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/sln.o /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/static-stubs.o  -Wl,-z,now -Wl,--start-group /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc.a -lgcc  -Wl,--end-group `ia64-unknown-linux-gnu-gcc  -pipe -g -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--as-needed  --print-file-name=crtend.o` /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/csu/crtn.o
/var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc.a(dl-support.o): in function `setup_vdso':
/var/tmp/portage/sys-libs/glibc-2.31-r3/work/glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text'
collect2: error: ld returned 1 exit status
"""
Comment 1 Sergei Trofimovich gentoo-dev 2020-05-15 21:08:23 UTC
> /var/tmp/portage/sys-libs/glibc-2.31-r3/work/glibc-2.31/elf/setup-vdso.h:116:(.text+0x1322): relocation truncated to fit: GPREL22 against `.text'

I think this short GPREL22 relocation comes from:

"""
$ objdump -d -S -r /var/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl
/libc.a

void
_dl_non_dynamic_init (void)
{
     780:       08 48 49 18 80 05       [MMI]       alloc r41=ar.pfs,18,12,0
...
static inline void __attribute__ ((always_inline))
setup_vdso (struct link_map *main_map __attribute__ ((unused)),
            struct link_map ***first_preload __attribute__ ((unused)))
{
#ifdef NEED_DL_SYSINFO_DSO
  if (GLRO(dl_sysinfo_dso) == NULL)
     860:       c2 70 04 00 00 24       [MII] (p06) mov r14=1
     866:       00 00 00 02 80 c3                   nop.i 0x0;;
     86c:       01 00 00 84                   (p07) mov r14=r0
     870:       04 38 01 02 00 24       [MLX]       addl r39=0,r1
                        870: GPREL22    _dl_sysinfo_dso
                        871: GPREL64I   .rodata.str1.8+0x8
"""

The _dl_sysinfo_dso reference is probably our candidate. I'm surprised it's not an LDXMOV / GPREL64I pair, but I don't remember specifics of loading local vs. global symbols.

Checking source file.
Comment 2 Sergei Trofimovich gentoo-dev 2020-05-15 23:00:13 UTC
gcc-9 generated full 64-bit relocation via MMI/MLX:

    8c0:	08 28 01 02 00 24 	[MMI]       addl r37=0,r1
			8c0: LTOFF22X	_dl_sysinfo_dso
			8c1: LTOFF22X	_dl_verbose
     8c6:	00 01 04 00 48 e0 	            addl r16=0,r1
     8cc:	05 00 00 84       	            mov r47=r0
     8d0:	05 70 01 00 00 21 	[MLX]       mov r46=r0
			8d1: GPREL64I	.rodata.str1.8+0x8

gcc-10 does local GPREL22:
     870:	04 28 01 02 00 24 	[MLX]       addl r37=0,r1
			870: GPREL22	_dl_sysinfo_dso
			871: GPREL64I	.rodata.str1.8+0x8
     876:	00 00 00 00 00 60 	            movl r43=0x0
     87c:	05 00 00 60 
     880:	09 80 00 02 00 24 	[MMI]       addl r16=0,r1
			880: GPREL22	_dl_verbose

I think it's a side-effect of -fno-common.

gcc used not to know that global variable is defined in the same module and pessimistically assumed 64-bit offset. But now if attempts a module-local reference via GPREL22.

At least we should be able to get an easy workaround.
Comment 3 Larry the Git Cow gentoo-dev 2020-05-15 23:12:23 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f43c7cd9e5a92d784af5e21ba22083cdb70c0e51

commit f43c7cd9e5a92d784af5e21ba22083cdb70c0e51
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-05-15 23:11:54 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-05-15 23:12:14 +0000

    sys-libs/glibc: avoid GPREL overflow on ia64, bug #723268
    
    -fno-common had unintended side-effect to optimise more
    accesses to global variables as module-local via GPREL22
    relocations. Unfortunately glibc is large enough to overflow
    GPREL22 offset.
    
    Let's add a -fcommon workaround back to pessimize code slightly
    that refers module-local globals. We'll need an equivalen of
    -fPIC to do it consistently.
    
    Bug: https://bugs.gentoo.org/723268
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30-r8.ebuild | 6 ++++++
 sys-libs/glibc/glibc-2.31-r3.ebuild | 6 ++++++
 sys-libs/glibc/glibc-9999.ebuild    | 6 ++++++
 3 files changed, 18 insertions(+)
Comment 4 Sergei Trofimovich gentoo-dev 2020-05-16 08:26:21 UTC
Slightly more performant workaround is to use -mno-sdata:


  // $ cat a.c
  int v;
  int read_v(void) { return v; }

  $ ia64-unknown-linux-gnu-gcc-10.1.0 -O2 -S a.c -o a-mno-sdata.S -mno-sdata
  $ ia64-unknown-linux-gnu-gcc-10.1.0 -O2 -S a.c -o a.S

  $ diff -y a.S a-mno-sdata.S

read_v:								read_v:
	.prologue							.prologue
	.body								.body
							      >		.mlx
							      >		nop 0
							      >		movl r14 = @gprel(v#)
							      >		;;
	.mmi								.mmi
	nop 0								nop 0
	addl r14 = @gprel(v#), gp			      |		add r14 = r1, r14
	nop 0								nop 0
	;;								;;

That way we still avoid PLT dereference but use slightly larger 64-bit form of gprel.
Given how small sdata for nowadays' programs maybe it's time to flip -mno-sdata on by default :)
Comment 5 Larry the Git Cow gentoo-dev 2020-05-16 08:58:10 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ec720b67f38952a4b9c6054c6d8ef0fc79d0343

commit 8ec720b67f38952a4b9c6054c6d8ef0fc79d0343
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-05-16 08:57:53 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-05-16 08:58:04 +0000

    sys-libs/glibc: use -mno-sdata, not -fcommon, bug #723268
    
    -fcommon generated PLT references and added double memory
    dereference.
    
    -mno-sdata is slightly more efficient as it still sees
    globals to be module local varilables and uses GPREL64
    (instead of PLT indirection) and uses single memory
    dereference.
    
    Bug: https://bugs.gentoo.org/723268
    Package-Manager: Portage-2.3.99, Repoman-2.3.22
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30-r8.ebuild | 3 ++-
 sys-libs/glibc/glibc-2.31-r3.ebuild | 3 ++-
 sys-libs/glibc/glibc-9999.ebuild    | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)
Comment 6 Sergei Trofimovich gentoo-dev 2020-05-16 09:46:46 UTC
Looking now at why we overflow 4MB range, that sounds like a lot for mere .sbss/.sdata binary. Usually it takes 1-2KB.

Looking at the precise error message:

  build-ia64-ia64-unknown-linux-gnu-nptl/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

it tells us that GPREL22 wants to encode an offset from 'gp' register (GP-REL-ative) to '.text' symbol (the very start of .text section).

'gp' normally points to start of '.got' section. Example layout for a hello world program:

  $ cat a.c
  int main(){}

  $ gcc -g a.c -o a
  $ gdb ./a
  (gdb) start
  Temporary breakpoint 1, main () at a.c:1 

  (gdb) print &main
  $1 = (int (*)()) 0x20000008000007f0 <main>
  (gdb) print (void*)$r1
  $2 = (void *) 0x2000000800010ec0

Note: $r1 is way below .text. I think GPREL relocations are signed.

Here is the section ordering (also match virtual address ordering):

$ readelf -S a

  ...
  [12] .text             PROGBITS         0000000000000640  00000640
       00000000000003e0  0000000000000000  AX       0     0     64
  ...
  [19] .data             PROGBITS         0000000000010e30  00000e30
       0000000000000004  0000000000000000  WA       0     0     4
  ...
  [23] .got              PROGBITS         0000000000010ec0  00000ec0
       0000000000000040  0000000000000000 WAp       0     0     8
  [24] .IA_64.pltoff     PROGBITS         0000000000010f00  00000f00
       0000000000000020  0000000000000000 WAp       0     0     16
  [25] .sdata            PROGBITS         0000000000010f20  00000f20
       0000000000000010  0000000000000000 WAp       0     0     8
  [26] .sbss             NOBITS           0000000000010f30  00000f30
       0000000000000008  0000000000000000 WAp       0     0     8
  [27] .bss              NOBITS           0000000000010f38  00000f30
       0000000000000008  0000000000000000  WA       0     0     8

Note: the distance from .text to .got is as big as a whole '.text' and '.data' are.

Ideally we should not use GPREL22 here.

Let's see what code makes that decision and if we can convince it not to.
Comment 7 Sergei Trofimovich gentoo-dev 2020-05-16 10:09:49 UTC
Looking at assembly file to see how GPREL instructions are usually encoded:

$ ia64-unknown-linux-gnu-gcc -O2 dl-support.c -S -std=gnu11 -fgnu89-inline  -O2 -fmerge-all-constants -frounding-math -fno-stack-protector -fmath-errno -ftls-model=initial-exec -U_FORTIFY_SOURCE -I../include -I/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf  -I/tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl  -I../sysdeps/unix/sysv/linux/ia64  -I../sysdeps/ia64/nptl  -I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/ia64/fpu  -I../sysdeps/ia64  -I../sysdeps/wordsize-64  -I../sysdeps/ieee754/float128  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/ia64-unknown-linux-gnu/10.1.0/include -isystem /usr/lib/gcc/ia64-unknown-linux-gnu/10.1.0/include-fixed -isystem /usr/ia64-unknown-linux-gnu/usr/include -D_LIBC_REENTRANT -include /tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=libc -include ../include/libc-symbols.h  -DPIC     -DTOP_NAMESPACE=glibc -o /tmp/portage/sys-libs/glibc-2.31-r3/work/build-ia64-ia64-unknown-linux-gnu-nptl/elf/dl-support.S

These are good 64-bit GPREL references into .rodata section:

...
.L228:
        .mlx
        nop 0
        movl r47 = @gprel(__PRETTY_FUNCTION__.1#)

        .section        .rodata.str1.8
        .align 8
__PRETTY_FUNCTION__.1:
        stringz "setup_vdso"

Theese are good 22-bit GPREL references into .sbss:

_dl_aux_init:
        .prologue
        .mmi
        alloc r16 = ar.pfs, 1, 12, 8, 0
        .body
        ld8 r14 = [r32]
        addl r15 = @gprel(_dl_auxv#), gp
...
        .section        .sbss
        .align 4
...
_dl_auxv:
        .skip   8
        .global _dl_correct_cache_id#

Let's assume _dl.*# are all in .sdata/.sbss and are small enough not to check them. The rest of gprel references are:

We have 3 suspicious references:

$ fgrep gprel elf/dl-support.S | fgrep -v 'movl ' | egrep -v '_dl.*#'

	(p7) addl r14 = @gprel(.LC1), gp

	addl r35 = @gprel(.LC17), gp

	(p7) addl r14 = @gprel(.LC1), gp

.LC1/.LC17 looks like a good .sdata reference:

  $ fgrep -C2 'LC1:' elf/dl-support.S
	.sdata
	.align 8
  .LC1:
	data8	.LC0+9
	.align 8

  .LC17:
        data8 unsecure_envvars.2#+275

Trying again to match against exact relocation.
Comment 8 Sergei Trofimovich gentoo-dev 2020-05-16 10:26:21 UTC
Matching object file back to GPREL22:

  build-ia64-ia64-unknown-linux-gnu-nptl/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

objdump shows the following code around 0x1322 offset:

  $ objdump -d -r -S elf/dl-support.o
    1300:       02 08 00 54 00 21       [MII]       mov r1=r42
                        1302: GPREL22   _dl_nns
      GL(dl_nns) = 1;
    1306:       10 09 00 00 48 e0                   mov r17=1;;
    130c:       01 08 00 90                         addl r15=0,r1
      if (GLRO(dl_sysinfo) == DL_SYSINFO_DEFAULT)
    1310:       0a 70 00 02 00 24       [MMI]       addl r14=0,r1;;
                        1310: GPREL22   _dl_sysinfo
                        1312: GPREL22   _dl_sysinfo_map
      GLRO(dl_sysinfo_map) = l;
    1316:       00 88 3c 30 23 e0                   st8 [r15]=r17
    131c:       01 08 00 90                         addl r15=0,r1
      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;;
        GLRO(dl_sysinfo) = GLRO(dl_sysinfo_dso)->e_entry + l->l_addr;
    1330:       0a 38 3c 20 06 f8       [MMI]       cmp.eq p7,p6=r15,r16;;
    1336:       01 01 9c 30 20 00             (p07) ld8 r16=[r39]
    133c:       00 00 04 00                         nop.i 0x0
    1340:       eb 88 00 42 18 d0       [MMI] (p07) ld8 r17=[r33];;
    1346:       01 c1 40 00 42 00             (p07) adds r16=24,r16
    134c:       00 00 04 00                         nop.i 0x0;;
    1350:       e3 78 00 20 18 10       [MII] (p07) ld8 r15=[r16]
    1356:       00 00 00 02 80 e3                   nop.i 0x0;;
    135c:       f1 88 00 80                   (p07) add r15=r15,r17;;
    1360:       e8 00 3c 1c 98 11       [MMI] (p07) st8 [r14]=r15
    1366:       00 00 00 02 00 00                   nop.m 0x0
    136c:       00 00 04 00                         nop.i 0x0

Grabbed a bit more to ease mapping back to source file.

Now matching against .S file shows only 2 places:

  $ fgrep 'ld8 r16 = [r14]' elf/dl-support.S
	ld8 r16 = [r14]
	ld8 r16 = [r14]


Looks about right:

  .L125:
        .mib
        mov r45 = r0
        mov r44 = r33
        br.call.sptk.many b0 = _dl_add_to_namespace_list#
        ;;
        .mii
        mov r1 = r42
        addl r17 = 1, r0
        ;;
        addl r15 = @gprel(_dl_nns#), gp
        .mmi
        addl r14 = @gprel(_dl_sysinfo#), gp
        ;;
        st8 [r15] = r17
        addl r15 = @gprel(_dl_sysinfo_map#), gp
        .mmi
        ld8 r16 = [r14] # <<<------- here is our dereference.
        ;;
        st8 [r15] = r33
        addl r15 = @gprel(_dl_sysinfo_break#), gp
        ;;

I think '.text' is unexpected here (as if '_dl_sysinfo_break#' was lost) and it's probably a glibc bug.

Compared to '_dl_nns#' / '_dl_sysinfo#' / '_dl_sysinfo_map#' global data symbols '_dl_sysinfo_break#' is an assemby-defined function.

sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:extern int _dl_sysinfo_break attribute_hidden;

sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:# define DL_SYSINFO_DEFAULT ((uintptr_t) &_dl_sysinfo_break)
sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:       ".hidden _dl_sysinfo_break\n\t"         \
sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:       ".proc _dl_sysinfo_break\n\t"           \
sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:       "_dl_sysinfo_break:\n\t"                        \
sysdeps/unix/sysv/linux/ia64/dl-sysdep.h:       ".endp _dl_sysinfo_break\n\t"           \

This confuses gcc into building invalid global references.
Comment 9 Sergei Trofimovich gentoo-dev 2020-05-16 10:46:40 UTC
The prototype mandling is intentional to avoid function descriptor indirection:

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ia64/dl-sysdep.h;h=78fa6dd2c97d752d0d229ea1a33b98e5c1623cb6;hb=HEAD#l35

"""
  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"            \
"""

I guess that code has to work before dynamic relocations are set up and that is the reason to avoid function descriptors.
Comment 10 Larry the Git Cow gentoo-dev 2020-05-16 11:30:57 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c6c63ec156e40e8b28724f2b49a8b0cf2ebf3033

commit c6c63ec156e40e8b28724f2b49a8b0cf2ebf3033
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-05-16 11:27:17 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-05-16 11:30:49 +0000

    sys-libs/glibc: revert "use -mno-sdata, not -fcommon, bug #723268"
    
    The underying linker failure cause is not just an overflow
    but a functional difference in '_dl_sysinfo_break' symbol linkage.
    
    '_dl_sysinfo_break' is defined as a function in assembly
    but declared as a global 'common' variable. Making it non-common
    actually breaks sysinfo handler which is expected to be called
    without function descriptor indirection. As sysonfo handler
    is called before rtld processed it's own relocations.
    
    Let's revert back to -fcommon until we have better glibc fix.
    
    This reverts commit 8ec720b67f38952a4b9c6054c6d8ef0fc79d0343.
    
    Bug: https://bugs.gentoo.org/723268
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30-r8.ebuild | 3 +--
 sys-libs/glibc/glibc-2.31-r3.ebuild | 3 +--
 sys-libs/glibc/glibc-9999.ebuild    | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)
Comment 11 Sergei Trofimovich gentoo-dev 2020-05-16 11:44:47 UTC
Created attachment 639630 [details, diff]
glibc-2.31-ia64-fno-common.patch

Testing glibc-2.31-ia64-fno-common.patch locally. It looks like the cleanest way to provide symbol hints to get GPREL64.
Comment 12 Sergei Trofimovich gentoo-dev 2020-05-16 13:55:21 UTC
(In reply to Sergei Trofimovich from comment #11)
> Created attachment 639630 [details, diff] [details, diff]
> glibc-2.31-ia64-fno-common.patch
> 
> Testing glibc-2.31-ia64-fno-common.patch locally. It looks like the cleanest
> way to provide symbol hints to get GPREL64.

Patch did not seem to break any vital tests. Proposed patch upstream as https://sourceware.org/pipermail/libc-alpha/2020-May/114028.html
Comment 13 Andreas K. Hüttel gentoo-dev 2020-07-18 16:15:07 UTC
Fixed in sys-libs/glibc-2.31-r6
Comment 14 Larry the Git Cow gentoo-dev 2020-07-18 16:58:45 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d99ab81692f0f04aa1421087c970ffd360163962

commit d99ab81692f0f04aa1421087c970ffd360163962
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-07-18 16:58:28 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-07-18 16:58:28 +0000

    sys-libs/glibc: drop -fcommon on ia64 (fixed in code)
    
    Glibc patchset now contains 0100-Fix-miscompilation-on-ia64-s-gcc-10.patch
    to workaround invalid relocation on ia64.
    
    Bug: https://bugs.gentoo.org/723268
    Package-Manager: Portage-2.3.103, Repoman-2.3.23
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.31-r6.ebuild | 6 ------
 sys-libs/glibc/glibc-9999.ebuild    | 6 ------
 2 files changed, 12 deletions(-)
Comment 15 Émeric Maschino 2020-10-17 14:50:49 UTC
Is it expected to hit this issue with =sys-libs/glibc-2.32-r2? I'm unable to compile any kernel with genkernel, the latter complaining with:

    [CC] liblvm2cmd.so
ia64-unknown-linux-gnu-gcc -shared -Wl,-soname,liblvm2cmd.so.2.02 \
	-Os -pipe -fomit-frame-pointer -I/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/include -fPIC -Wl,--version-script,.export.sym -L../libdm -L../lib -L../libdaemon/client -L../daemons/dmeventd -o liblvm2cmd.so \
	-Wl,-whole-archive liblvm2cmd.a -Wl,-no-whole-archive \
	-llvm-internal ../base/libbase.a -ldevmapper-event -ldaemonclient  -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -ludev  -ldl -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -lblkid  -ldevmapper -laio 
/usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.o): in function `printf_positional':
(.text+0x1571): relocation truncated to fit: GPREL22 against symbol `__printf_arginfo_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-printf.o)
(.text+0x16e2): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
(.text+0x41c2): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
/usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.o): in function `__vfprintf_internal':
(.text+0x53b1): relocation truncated to fit: GPREL22 against symbol `__printf_va_arg_table' defined in __libc_freeres_ptrs section in /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
collect2: error: ld returned 1 exit status
Comment 16 Sergei Trofimovich gentoo-dev 2020-10-17 23:01:08 UTC
(In reply to Émeric Maschino from comment #15)
> Is it expected to hit this issue with =sys-libs/glibc-2.32-r2?

=sys-libs/glibc-2.32-r2 has a fix for it.

> I'm unable to
> compile any kernel with genkernel, the latter complaining with:

That is probably a different issue.

>     [CC] liblvm2cmd.so
> ia64-unknown-linux-gnu-gcc -shared -Wl,-soname,liblvm2cmd.so.2.02 \
> 	-Os -pipe -fomit-frame-pointer
> -I/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/include -fPIC
> -Wl,--version-script,.export.sym -L../libdm -L../lib -L../libdaemon/client
> -L../daemons/dmeventd -o liblvm2cmd.so \
> 	-Wl,-whole-archive liblvm2cmd.a -Wl,-no-whole-archive \
> 	-llvm-internal ../base/libbase.a -ldevmapper-event -ldaemonclient 
> -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -ludev  -ldl
> -L/var/tmp/genkernel/gk_VUq18tKK/lvm/buildroot/usr/lib -lblkid  -ldevmapper
> -laio 
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.
> o): in function `printf_positional':
> (.text+0x1571): relocation truncated to fit: GPREL22 against symbol
> `__printf_arginfo_table' defined in __libc_freeres_ptrs section in
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-printf.o)
> (.text+0x16e2): relocation truncated to fit: GPREL22 against symbol
> `__printf_va_arg_table' defined in __libc_freeres_ptrs section in
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
> (.text+0x41c2): relocation truncated to fit: GPREL22 against symbol
> `__printf_va_arg_table' defined in __libc_freeres_ptrs section in
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(vfprintf-internal.
> o): in function `__vfprintf_internal':
> (.text+0x53b1): relocation truncated to fit: GPREL22 against symbol
> `__printf_va_arg_table' defined in __libc_freeres_ptrs section in
> /usr/lib/gcc/ia64-unknown-linux-gnu/10.2.0/../../../libc.a(reg-type.o)
> collect2: error: ld returned 1 exit status

Specifically it tries to link in static libc into a shared library. That looks very wrong.
Comment 17 Émeric Maschino 2020-10-18 08:49:03 UTC
Will then report. Against sys-kernel/genkernel?
Comment 18 Sergei Trofimovich gentoo-dev 2020-10-18 09:11:29 UTC
That should be a good start.
Comment 19 Émeric Maschino 2020-10-18 15:01:22 UTC
(In reply to Sergei Trofimovich from comment #18)
> That should be a good start.

Done: bug #749957 for interested people.