On 6 Dec 2021, at 21:28, Konstantin Belousov <[email protected]> wrote: > > On Mon, Dec 06, 2021 at 08:51:02PM +0000, Jessica Clarke wrote: >> On 6 Dec 2021, at 18:48, Konstantin Belousov <[email protected]> wrote: >>> >>> The branch main has been updated by kib: >>> >>> URL: >>> https://cgit.FreeBSD.org/src/commit/?id=ab4524b3d7fba872a143b03c9346cb04c3670efa >>> >>> commit ab4524b3d7fba872a143b03c9346cb04c3670efa >>> Author: Konstantin Belousov <[email protected]> >>> AuthorDate: 2021-11-05 08:07:24 +0000 >>> Commit: Konstantin Belousov <[email protected]> >>> CommitDate: 2021-12-06 18:46:49 +0000 >>> >>> amd64: wrap 64bit sigtramp into vdso >>> >>> Reviewed by: emaste >>> Discussed with: jrtc27 >>> Tested by: pho >>> Sponsored by: The FreeBSD Foundation >>> MFC after: 1 month >>> Differential revision: https://reviews.freebsd.org/D32960 >> >> This broke cross-building from non-FreeBSD: >> >>> ERROR: ctfconvert: elf-vdso.so.o doesn't have type data to convert >> >> The error message also shows up on FreeBSD, but ctfconvert has a gross >> #ifdef __FreeBSD__ hack in it to make it non-fatal (dating right back >> to when it was imported), which of course doesn’t work when building on >> non-FreeBSD, and is something I’ve wanted to remove from FreeBSD too as >> silently allowing broken CTF is a bad idea these days (see AArch64 >> where LLVM 13 bogusly emits DWARF using C++ constructs for C, breaking >> CTF entirely, which wasn’t caught until it was built on non-FreeBSD). >> >> I imagine this just needs no-ctfconvert in files.amd64 for both VDSOs? > > I have no idea. If you think it is the right fix for your problem, go ahead? > I doubt that vdso wrapper objects would ever carry anything that resemble > type info, or that could be useful as the dtrace material.
Sure, I have other cross-build changes to push too as the world isn’t quite unbroken after the libdwarf change (Linux is happy now, but macOS isn’t due to libcrypt not being a thing there... whack-a-mole continues). > BTW, we have enough .S files that do not generate any dwarf data. Why is it > not a same problem? I imagine because we list the .S not the resulting .o in files? Jess
