[llvm-bugs] [Bug 43942] New: Clang or lld generates invalid short relocation for Google Chrome with debuginfo

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43942

            Bug ID: 43942
           Summary: Clang or lld generates invalid short relocation for
                    Google Chrome with debuginfo
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: conrad.meyer at isilon.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Possibly related to bug 15356 or bug 21423.

When linking a debug build of recent Chrome (78.x), with recent Clang+LLD
(9.0.0), ld.lld fails due to 32-bit relocations on >4GB offsets:

> ld.lld: error: /usr/lib/crtn.o:(.debug_aranges+0x6): relocation R_X86_64_32 out of range: 4357891405 is not in [0, 4294967295]; consider recompiling with -fdebug-types-section to reduce size of debug sections

I'm not sure what I'm supposed to do about this as an end-user.  Chrome is just
a gigantic program:

$ c++ -Wl,--version-script=../../build/linux/chrome.map -fPIC
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fuse-ld=lld -Wl,--color-diagnostics
-m64 -rdynamic -pie -Wl,--disable-new-dtags -L/usr/local/lib
-L/usr/local/lib/nss  -fstack-protector-strong -L/usr/local/lib  -o "./chrome"
-Wl,--start-group @"./chrome.rsp"  -Wl,--end-group ... (-lfoo -lbar from here)

$ cat chrome.rsp  | tr ' ' '\0' | xargs -0 du -csh
...
3.7G

Should Clang (or lld?) emit 64-bit relocations automatically?  Do I need to ask
the Chrome folks to use some large data mode flag?  They already use -fPIC
rather than
-fpic.

       -fPIC
           If supported for the target machine, emit position-independent
           code, suitable for dynamic linking and avoiding any limit on the
           size of the global offset table.

(From the gcc manual page.)  Also gcc:

       -mcmodel=small
           Generate code for the small code model: the program and its symbols
           must be linked in the lower 2 GB of the address space.  Pointers
           are 64 bits.  Programs can be statically or dynamically linked.
           This is the default code model.

       -mcmodel=medium
           Generate code for the medium model: the program is linked in the
           lower 2 GB of the address space.  Small symbols are also placed
           there.  Symbols with sizes larger than -mlarge-data-threshold are
           put into large data or BSS sections and can be located above 2GB.
           Programs can be statically or dynamically linked.

       -mcmodel=large
           Generate code for the large model.  This model makes no assumptions
           about addresses and sizes of sections.

Here's Clang's full documentation on -mcmodel:

https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mcmodel

(Yeah, that's not helpful.)

Maybe -mcmodel is passed through to cc1 as -mcode-model= here:
https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/Clang.cpp#L4320

The scenario seems pretty similar to this test case:
https://github.com/llvm/llvm-project/blob/master/lld/test/ELF/x86-64-reloc-debug-overflow.s

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191108/a9179f05/attachment.html>