New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 822053 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Apr 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug
Build-Toolchain



Sign in to add a comment

sys-devel/gdb fails to build when SHT_RELR sections are enabled

Project Member Reported by rahulchaudhry@chromium.org, Mar 14 2018

Issue description

I am testing support for SHT_RELR sections in chromium os. SHT_RELR sections are used to compactly store all the R_X86_64_RELATIVE relocations in a PIE binary or a shared object. For more background, see the official proposal here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg

SHT_RELR sections do not support relative relocations with odd offsets.
This results in sys-devel/gdb failing to build when SHT_RELR sections are enabled.

Steps to reproduce:

1. setup_board --board=chell
2. build_packages --board=chell
3. cherry pick https://chromium-review.googlesource.com/733802
4. sudo emerge cross-x86_64-cros-linux-gnu/binutils
5. emerge-chell sys-devel/gdb

fails with:

/usr/x86_64-pc-linux-gnu/x86_64-cros-linux-gnu/binutils-bin/2.27.0/ld.gold.real: internal error in shrink_relocs, at /var/tmp/portage/cross-x86_64-cros-linux-gnu/binutils-2.27.0-r6/work/binutils-2.27.0/binutils-2.27/gold/output.h:2527
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)

when linking the 'gdb' binary.

The relevant assert in gold linker is just checking that the offset is not odd:

2526         // Odd addresses are not supported in SHT_RELR.
2527         gold_assert(current%2 == 0);

 
The gdb binary is built as PIE (position independent executable).
It has 21640 relocation entries.
Out of these, 21502 are R_X86_64_RELATIVE relocations.
And out of these, 7 relocations have odd offsets:

Relocation section '.rela.dyn' at offset 0x4bf8 contains 21640 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
000000000068971b  0000000000000008 R_X86_64_RELATIVE                         5aceb0
0000000000689723  0000000000000008 R_X86_64_RELATIVE                         5aceb0
0000000000689aa9  0000000000000008 R_X86_64_RELATIVE                         5aceb0
0000000000689ab1  0000000000000008 R_X86_64_RELATIVE                         5aceb0
000000000068a3d1  0000000000000008 R_X86_64_RELATIVE                         5ace90
000000000068a3d9  0000000000000008 R_X86_64_RELATIVE                         5aceb0
000000000068aa0d  0000000000000008 R_X86_64_RELATIVE                         5aceb0

2 of these relocations with odd offsets are in section starting with <lang_frame_mismatch_warn>.
"objdump -D -z -M intel -R gdb" shows:

0000000000689a70 <lang_frame_mismatch_warn>:
  689a70:       57                      push   rdi
  689a71:       61                      (bad)
  689a72:       72 6e                   jb     689ae2 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x12>
  689a74:       69 6e 67 3a 20 74 68    imul   ebp,DWORD PTR [rsi+0x67],0x6874203a
  689a7b:       65 20 63 75             and    BYTE PTR gs:[rbx+0x75],ah
  689a7f:       72 72                   jb     689af3 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x23>
  689a81:       65 6e                   outs   dx,BYTE PTR gs:[rsi]
  689a83:       74 20                   je     689aa5 <lang_frame_mismatch_warn+0x35>
  689a85:       6c                      ins    BYTE PTR es:[rdi],dx
  689a86:       61                      (bad)
  689a87:       6e                      outs   dx,BYTE PTR ds:[rsi]
  689a88:       67 75 61                addr32 jne 689aec <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x1c>
  689a8b:       67 65 20 64 6f 65       and    BYTE PTR gs:[edi+ebp*2+0x65],ah
  689a91:       73 20                   jae    689ab3 <lang_frame_mismatch_warn+0x43>
  689a93:       6e                      outs   dx,BYTE PTR ds:[rsi]
  689a94:       6f                      outs   dx,DWORD PTR ds:[rsi]
  689a95:       74 20                   je     689ab7 <lang_frame_mismatch_warn+0x47>
  689a97:       6d                      ins    DWORD PTR es:[rdi],dx
  689a98:       61                      (bad)
  689a99:       74 63                   je     689afe <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x2e>
  689a9b:       68 20 74 68 69          push   0x69687420
  689aa0:       73 20                   jae    689ac2 <return_child_result_value+0x2>
  689aa2:       66 72 61                data16 jb 689b06 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x36>
  689aa5:       6d                      ins    DWORD PTR es:[rdi],dx
  689aa6:       65 2e 00 b0 ce 5a 00    gs add BYTE PTR cs:[rax+0x5ace],dh
  689aad:       00 
                        689aa9: R_X86_64_RELATIVE       *ABS*+0x5aceb0
  689aae:       00 00                   add    BYTE PTR [rax],al
  689ab0:       00 b0 ce 5a 00 00       add    BYTE PTR [rax+0x5ace],dh
                        689ab1: R_X86_64_RELATIVE       *ABS*+0x5aceb0
  689ab6:       00 00                   add    BYTE PTR [rax],al
  689ab8:       00 00                   add    BYTE PTR [rax],al
  689aba:       00 00                   add    BYTE PTR [rax],al
  689abc:       00 00                   add    BYTE PTR [rax],al
  689abe:       00 00                   add    BYTE PTR [rax],al

Note the two R_X86_64_RELATIVE relocations on odd offsets.

Symbol 'lang_frame_mismatch_warn' is defined in language.c as:

char lang_frame_mismatch_warn[] = "Warning: the current language does not match this frame.";

Interestingly, if sys-devel/gdb is built using gcc, the relocations with odd offsets do not appear.
Here's the corresponding objdump of gdb PIE binary built with gcc:

00000000006a6e60 <lang_frame_mismatch_warn>:   
  6a6e60:       57                      push   rdi
  6a6e61:       61                      (bad)  
  6a6e62:       72 6e                   jb     6a6ed2 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x12>
  6a6e64:       69 6e 67 3a 20 74 68    imul   ebp,DWORD PTR [rsi+0x67],0x6874203a
  6a6e6b:       65 20 63 75             and    BYTE PTR gs:[rbx+0x75],ah
  6a6e6f:       72 72                   jb     6a6ee3 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x23>
  6a6e71:       65 6e                   outs   dx,BYTE PTR gs:[rsi]
  6a6e73:       74 20                   je     6a6e95 <lang_frame_mismatch_warn+0x35>
  6a6e75:       6c                      ins    BYTE PTR es:[rdi],dx
  6a6e76:       61                      (bad)  
  6a6e77:       6e                      outs   dx,BYTE PTR ds:[rsi]
  6a6e78:       67 75 61                addr32 jne 6a6edc <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x1c>
  6a6e7b:       67 65 20 64 6f 65       and    BYTE PTR gs:[edi+ebp*2+0x65],ah
  6a6e81:       73 20                   jae    6a6ea3 <current_language+0x3>
  6a6e83:       6e                      outs   dx,BYTE PTR ds:[rsi]
  6a6e84:       6f                      outs   dx,DWORD PTR ds:[rsi]
  6a6e85:       74 20                   je     6a6ea7 <current_language+0x7>
  6a6e87:       6d                      ins    DWORD PTR es:[rdi],dx
  6a6e88:       61                      (bad)
  6a6e89:       74 63                   je     6a6eee <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x2e>
  6a6e8b:       68 20 74 68 69          push   0x69687420
  6a6e90:       73 20                   jae    6a6eb2 <return_child_result_value+0xa>
  6a6e92:       66 72 61                data16 jb 6a6ef6 <_ZZL15captured_main_1P18captured_main_argsE12long_options+0x36>
  6a6e95:       6d                      ins    DWORD PTR es:[rdi],dx
  6a6e96:       65 2e 00 00             gs add BYTE PTR cs:[rax],al
  6a6e9a:       00 00                   add    BYTE PTR [rax],al
  6a6e9c:       00 00                   add    BYTE PTR [rax],al
  6a6e9e:       00 00                   add    BYTE PTR [rax],al

All of the 7 problematic odd offset relocations disappear when building with gcc.
Looking at the language.o object file differences between gcc and clang builds.

Here's the <lang_frame_mismatch_warn> from language.o compiled with gcc:

0000000000000000 <lang_frame_mismatch_warn>:
   0:   57                      push   rdi
   1:   61                      (bad)  
   2:   72 6e                   jb     72 <.LC34+0xf>
   4:   69 6e 67 3a 20 74 68    imul   ebp,DWORD PTR [rsi+0x67],0x6874203a
   b:   65 20 63 75             and    BYTE PTR gs:[rbx+0x75],ah
   f:   72 72                   jb     83 <.LC35+0x9>
  11:   65 6e                   outs   dx,BYTE PTR gs:[rsi]
  13:   74 20                   je     35 <lang_frame_mismatch_warn+0x35>
  15:   6c                      ins    BYTE PTR es:[rdi],dx
  16:   61                      (bad)  
  17:   6e                      outs   dx,BYTE PTR ds:[rsi]
  18:   67 75 61                addr32 jne 7c <.LC35+0x2>
  1b:   67 65 20 64 6f 65       and    BYTE PTR gs:[edi+ebp*2+0x65],ah
  21:   73 20                   jae    43 <_ZL19unk_lang_class_namePKc+0x3>
  23:   6e                      outs   dx,BYTE PTR ds:[rsi]
  24:   6f                      outs   dx,DWORD PTR ds:[rsi]
  25:   74 20                   je     47 <_ZL19unk_lang_class_namePKc+0x7>
  27:   6d                      ins    DWORD PTR es:[rdi],dx
  28:   61                      (bad)  
  29:   74 63                   je     8e <.LC35+0x14>
  2b:   68 20 74 68 69          push   0x69687420
  30:   73 20                   jae    52 <_Z25default_print_array_indexP5valueP7ui_filePK19value_print_options+0x2>
  32:   66 72 61                data16 jb 96 <.LC37+0x3>
  35:   6d                      ins    DWORD PTR es:[rdi],dx
  36:   65                      gs
  37:   2e                      cs     
  38:   00                      .byte 0x0


And here's the disassembly from language.o compiled with clang:

0000000000000010 <lang_frame_mismatch_warn>:
  10:   57                      push   rdi
  11:   61                      (bad)  
  12:   72 6e                   jb     82 <_Z13language_infoi+0x12>
  14:   69 6e 67 3a 20 74 68    imul   ebp,DWORD PTR [rsi+0x67],0x6874203a
  1b:   65 20 63 75             and    BYTE PTR gs:[rbx+0x75],ah
  1f:   72 72                   jb     93 <.L.str.8+0x4>
  21:   65 6e                   outs   dx,BYTE PTR gs:[rsi]
  23:   74 20                   je     45 <lang_frame_mismatch_warn+0x35>
  25:   6c                      ins    BYTE PTR es:[rdi],dx
  26:   61                      (bad)  
  27:   6e                      outs   dx,BYTE PTR ds:[rsi]
  28:   67 75 61                addr32 jne 8c <_Z13language_infoi+0x1c>
  2b:   67 65 20 64 6f 65       and    BYTE PTR gs:[edi+ebp*2+0x65],ah
  31:   73 20                   jae    53 <.L.str.5+0x1>
  33:   6e                      outs   dx,BYTE PTR ds:[rsi]
  34:   6f                      outs   dx,DWORD PTR ds:[rsi]
  35:   74 20                   je     57 <.L.str.5+0x5>
  37:   6d                      ins    DWORD PTR es:[rdi],dx
  38:   61                      (bad)
  39:   74 63                   je     9e <.L.str.8+0xf>
  3b:   68 20 74 68 69          push   0x69687420
  40:   73 20                   jae    62 <_ZL4type+0x2>
  42:   66 72 61                data16 jb a6 <.L.str.8+0x17>
  45:   6d                      ins    DWORD PTR es:[rdi],dx
  46:   65 2e 00 00             gs add BYTE PTR cs:[rax],al
                        49: R_X86_64_64 _ZTI31gdb_exception_RETURN_MASK_ERROR
  4a:   00 00                   add    BYTE PTR [rax],al
  4c:   00 00                   add    BYTE PTR [rax],al
  4e:   00 00                   add    BYTE PTR [rax],al
  50:   00                      .byte 0x0

Note the new relocation at 49 that wasn't there in the gcc version.
It's pointing to symbol '_ZTI31gdb_exception_RETURN_MASK_ERROR'.
This R_X86_64_64 turns into an R_X86_64_RELATIVE with odd offset in the final binary.

Owner: rahulchaudhry@chromium.org
Status: Started (was: Untriaged)
Project Member

Comment 6 by bugdroid1@chromium.org, Mar 16 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/3c024476dded0e78837b72d090c34d7f342159ad

commit 3c024476dded0e78837b72d090c34d7f342159ad
Author: Rahul Chaudhry <rahulchaudhry@chromium.org>
Date: Fri Mar 16 06:44:05 2018

sys-devel/gdb: append '--no-experimental-use-relr' to ldflags.

This is the default behavior of gold linker right now, so this CL does
not change any behavior. We are preparing for SHT_RELR sections to be
enabled by default in gold.

BUG= chromium:822053 
TEST='emerge-chell sys-devel/gdb' works with SHT_RELR sections enabled in gold.

Change-Id: I2ca42a5cf3127eb9f593999e18e28af89435efbb
Reviewed-on: https://chromium-review.googlesource.com/965114
Commit-Ready: Rahul Chaudhry <rahulchaudhry@chromium.org>
Tested-by: Rahul Chaudhry <rahulchaudhry@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>

[rename] https://crrev.com/3c024476dded0e78837b72d090c34d7f342159ad/sys-devel/gdb/gdb-8.0.1.20171030-r4.ebuild
[modify] https://crrev.com/3c024476dded0e78837b72d090c34d7f342159ad/sys-devel/gdb/gdb-8.0.1.20171030.ebuild

Project Member

Comment 7 by bugdroid1@chromium.org, Mar 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/9615b4b6f3febf815571ec4e45f221af4f981113

commit 9615b4b6f3febf815571ec4e45f221af4f981113
Author: Rahul Chaudhry <rahulchaudhry@chromium.org>
Date: Fri Mar 30 02:51:32 2018

sys-devel/llvm: apply a patch to align compiler generated stubs.

Align stubs for external and common global variables to pointer size.

Locally patch differential revision https://reviews.llvm.org/D44848
until it is merged upstream.

BUG= chromium:822053 
BUG= chromium:824983 
TEST='sudo emerge sys-devel/llvm' works.
TEST='emerge-chell sys-devel/gdb' works with SHT_RELR sections enabled in gold.
TEST='emerge-guado_moblab media-libs/qhull' works with SHT_RELR sections enabled in gold.

Change-Id: I4305fda5b801664be2090f103808ef32655e6931
Reviewed-on: https://chromium-review.googlesource.com/984778
Commit-Ready: Rahul Chaudhry <rahulchaudhry@chromium.org>
Tested-by: Rahul Chaudhry <rahulchaudhry@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>

[rename] https://crrev.com/9615b4b6f3febf815571ec4e45f221af4f981113/sys-devel/llvm/llvm-7.0_pre326829_p20180318-r3.ebuild
[rename] https://crrev.com/9615b4b6f3febf815571ec4e45f221af4f981113/sys-devel/gdb/gdb-8.0.1.20171030-r5.ebuild
[modify] https://crrev.com/9615b4b6f3febf815571ec4e45f221af4f981113/sys-devel/gdb/gdb-8.0.1.20171030.ebuild
[add] https://crrev.com/9615b4b6f3febf815571ec4e45f221af4f981113/sys-devel/llvm/files/llvm-7.0-stub-alignment.patch

Status: Fixed (was: Started)

Sign in to add a comment