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

On 6 Dec 2021, at 21:28, Konstantin Belousov <kostikbel@gmail.com> wrote:
> 
> 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.

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