PATCH: PR libstdc++/14098

[Loren James Rittle]

In article <20040211002138.1d98acbc.bkoz@redhat.com>,
Benjamin Kosnik<bkoz@redhat.com> writes:

>> May be the tip of the iceberg, I'm afraid...

> We need a better way of determining this info. LSB did have some
> commentary on this issue, and instructions as to how we can figure this
> stuff out: see the TODO, search the LSB list, or ping me.

At a first-order, seems we could automate looking for cases where X
was "visible" in the final image but typeinfo X, etc was "hidden".

It is my assumption that our test suite already directly catches
most/all mis-marked primary X...

Manually checking...

$ objdump --syms -C libstdc++.so.6 | grep typeinfo
00064d1a l O .rodata 0000001a typeinfo name for std::__moneypunct_cache<char>
00064d34 l O .rodata 00000018 typeinfo name for std::__numpunct_cache<char>
00067470 l O .data   0000000c typeinfo for std::__moneypunct_cache<char>
0006496a l O .rodata 00000019 typeinfo name for std::__timepunct_cache<char>
00063b60 l O .rodata 0000002f typeinfo name for __gnu_cxx::demangler::implementation_details
00067490 l O .data   0000000c typeinfo for std::__numpunct_cache<char>
0006645c l O .data   00000008 typeinfo for __gnu_cxx::demangler::implementation_details
00066f48 l O .data   0000000c typeinfo for std::__timepunct_cache<char>
[... all w entries after here...]

Looking at related X entries (automate as new pass in check abi tool?)
shows that only __gnu_cxx::demangler::implementation_details matches
as local.  Humm, users shouldn't be referring to std::__xxx_cache so I
guess the point is moot here and we have no other icebergs at the moment...

Yippy!

Regards,
Loren