Re: git: ab4524b3d7fb - main - amd64: wrap 64bit sigtramp into vdso

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Mon, 06 Dec 2021 21:28:05 UTC
On Mon, Dec 06, 2021 at 08:51:02PM +0000, Jessica Clarke wrote:
> On 6 Dec 2021, at 18:48, Konstantin Belousov <kib@FreeBSD.org> wrote:
> > 
> > The branch main has been updated by kib:
> > 
> > URL: https://cgit.FreeBSD.org/src/commit/?id=ab4524b3d7fba872a143b03c9346cb04c3670efa
> > 
> > commit ab4524b3d7fba872a143b03c9346cb04c3670efa
> > Author:     Konstantin Belousov <kib@FreeBSD.org>
> > AuthorDate: 2021-11-05 08:07:24 +0000
> > Commit:     Konstantin Belousov <kib@FreeBSD.org>
> > 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.

BTW, we have enough .S files that do not generate any dwarf data.  Why is it
not a same problem?