Date: Wed, 23 Dec 2020 02:31:18 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 248516] elftoolchain error when building linux_vdso.so with llvm objcopy Message-ID: <bug-248516-29464-WaIpIj9m62@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-248516-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-248516-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248516 Jessica Clarke <jrtc27@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrtc27@freebsd.org --- Comment #4 from Jessica Clarke <jrtc27@freebsd.org> --- Did you try loading the final linux64 module? It looks from your diff like llvm-objcopy hasn't created the _binary_$file symbols in the first place an= d so the symbol table doesn't exist (hence the error). I expect you will get an error like `link_elf: symbol _binary_linux_locore_o_end undefined` when try= ing to load the resulting module, something which I see downstream in CheriBSD built with LLVM for Morello. so I think there are two bugs in play: 1. elftoolchain's strip doesn't like being fed an ELF with no .symtab 2. llvm-objcopy isn't creating the _binary_$file symbols Looking more closely at 2, it appears that llvm-objcopy erroneously applies= -S to the output file when using -I binary; it's meant to skip copying relocat= ion and symbol information from the source file, but presumably it gets confused and forgets that the relocation and symbol information it's generating is self-constructed. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248516-29464-WaIpIj9m62>