Summary: | head -r310854: lldb.full gets various "relocation truncated to fit: R_ARM_CALL against symbol ... defined in .plt section in ..." failure messages | ||
---|---|---|---|
Product: | Base System | Reporter: | Mark Millard <marklmi26-fbsd> |
Component: | bin | Assignee: | Ed Maste <emaste> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | emaste |
Priority: | --- | Flags: | koobs:
maintainer-feedback?
(emaste) koobs: mfc-stable13? koobs: mfc-stable12? |
Version: | CURRENT | ||
Hardware: | arm | ||
OS: | Any | ||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229050 |
Description
Mark Millard
2017-01-01 07:59:16 UTC
The issue is that lldb is too large and requires a linker that supports range extension thunks. I believe you're linking with in-tree GNU ld and that it does not support them. Right now you could try using a cross-binutils port. There are lld patches in review for range extension thunks: 1. https://reviews.llvm.org/D34689 2. https://reviews.llvm.org/D34691 3. https://reviews.llvm.org/D34692 4. https://reviews.llvm.org/D35413 1 and 2 are probably sufficient to address this issue, 3 and 4 are part of a complete & more optimized implementation. I'm not quite sure what they're waiting on upstream, but presumably they will be committed to lld head soon and we will most likely backport them to lld 5.0.0 in FreeBSD-current. This should be working for armv7 with lld 6.0. More work is still needed for arm/armv6 - see PR 229050. (In reply to Ed Maste from comment #2) I tried building head -r358996 lldb for armv7 and the build reported no errors. (So, based on system llvm 10 materials.) (I do, by default, use -mcpu=cortex-a7 explicitly for armv7.) I also tried building world (lldb included) and kernel for armv6 and the build reported no errors. (no -mcpu or other such additions). I've not tested operation but this report was about the build failure, not operation. I do not know the status of this for system llvm9 or before materials or for stable/11 or stable/12 . It looks like llvm10 materials are planned to be MFC'd (to at least 12?). So I'm not sure about if the context is sufficient to close this as fixed overall (yet). Relative to head it could be closed as fixed. @Ed Is this now resolved? If so, please assign to committer that resolves and set relevent mfc-stable branches (to + if merged, or - if mfc did not apply). |