Page MenuHomeFreeBSD

Remove a workaround for old ld.bfd not understanding modern C++ types.
Needs ReviewPublic

Authored by jhb on Jun 2 2020, 4:46 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 2 2024, 3:54 AM
Unknown Object (File)
Jan 1 2024, 4:18 AM
Unknown Object (File)
Aug 24 2023, 1:03 AM
Unknown Object (File)
Jul 2 2023, 4:27 AM
Unknown Object (File)
May 9 2023, 11:27 PM
Unknown Object (File)
May 7 2023, 6:34 PM
Unknown Object (File)
Dec 10 2022, 4:10 PM
Subscribers

Details

Reviewers
emaste
Summary

Use named symbols for typeinfo for newer types instead of the mangled
names.

Test Plan
  • I tried to build world with this, but it fails.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 31443
Build 29059: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Jun 2 2020, 4:46 PM

I'm uploading this before I give up in case someone else wants to fix this. lld seems to be broken still (I haven't tried modern ld.bfd). It uses the wrong names for nullptr, half and char32_t so world fails to link. I also can't for the life of me figure out which part of typeinfo.cc generates these symbols, but nm of the individual object files shows them defined in typeinfo.o from the libcxxrt build.

The broken symbols from nm | c++filt of libcxxrt built with this change on amd64:

000000000001c0b8 d typeinfo for half
000000000001c2e8 D typeinfo for char32_t
000000000001bbb8 d typeinfo for decltype(nullptr)
000000000001c298 D typeinfo for char16_t
000000000001c248 d _ZTIDu
...
000000000001c0c8 d typeinfo for half*
000000000001c2f8 D typeinfo for char32_t*
000000000001bbc8 d typeinfo for decltype(nullptr)*
000000000001c2a8 D typeinfo for char16_t*
000000000001c258 d _ZTIPDu
000000000001c0e8 d typeinfo for half const*
000000000001c318 D typeinfo for char32_t const*
000000000001bbe8 d typeinfo for decltype(nullptr) const*
000000000001c2c8 D typeinfo for char16_t const*
000000000001c278 d _ZTIPKDu
...
0000000000008311 r typeinfo name for half
0000000000008359 R typeinfo name for char32_t
000000000000827e r typeinfo name for decltype(nullptr)
000000000000834d R typeinfo name for char16_t
0000000000008341 r _ZTSDu
...
0000000000008314 r typeinfo name for half*
000000000000835c R typeinfo name for char32_t*
0000000000008281 r typeinfo name for decltype(nullptr)*
0000000000008350 R typeinfo name for char16_t*
0000000000008344 r _ZTSPDu
0000000000008318 r typeinfo name for half const*
0000000000008360 R typeinfo name for char32_t const*
0000000000008285 r typeinfo name for decltype(nullptr) const*
0000000000008354 R typeinfo name for char16_t const*
0000000000008348 r _ZTSPKDu
...

The `__float128` types also seem broken.  In particular, notice that clang appears to have used the unsigned suffix ('u') for `char32_t` instead of 'i' so c++filt can't decode it, and that the typeinfo classes for 'nullptr', 'half', 'char32_t' and `__float128` all are private ('r' vs 'R').  The actual error I get during buildworld is that a C++ program fails to link due to missing typeinfo for `nullptr`.

Hmm, FWIW, the `char32_t` and `__float128` issues seem to be just as broken on a stable/12 box using the current Version.map (also 'r' vs 'R') and c++filt also fails to decode `char32_t` for the same reason.  __float128 just seems to be missing from this file.

So I think the current issues might be:

1) lld doesn't properly mangle nullptr and half (have not tested a build with modern ld.bfd to see if it gets this right).

2) clang uses 'u' instead of 'i' suffix for char32_t (old bug, have not compared with modern GCC)

3) Missing entries in Version.map for __float128 types (old bug)
lib/libcxxrt/Version.map
80

The sorting of these sections seems haphazard and inconsistent between sections. I tried to match what each section did?