search for: hiddenclassa

...uplicate all the can_be_hidden symbols to reduce code size. This can't be achieved when the symbols is private external. If I understand you correctly, ld64 will deduplicate std::vector<int>::push_back and std::vector<unsigned>::push_back, but it will not deduplicate std::vector<HiddenClassA>::push_back and std::vector<HiddenClassB>::push_back. Is that correct? Do you know why it has that limitation? Thanks, Rafael

..._be_hidden symbols to reduce code size. This can't be achieved when the symbols is private external. > > If I understand you correctly, ld64 will deduplicate > std::vector<int>::push_back and std::vector<unsigned>::push_back, but it > will not deduplicate std::vector<HiddenClassA>::push_back and > std::vector<HiddenClassB>::push_back. Is that correct? Do you know why > it has that limitation? ld64 will dedup identical atoms regardless of names which helps in the case of templates with same underlying types. > > Thanks, > Rafael

...ls to reduce code size. This can't be achieved when the symbols is private external. >> >> If I understand you correctly, ld64 will deduplicate >> std::vector<int>::push_back and std::vector<unsigned>::push_back, but it >> will not deduplicate std::vector<HiddenClassA>::push_back and >> std::vector<HiddenClassB>::push_back. Is that correct? Do you know why >> it has that limitation? > > ld64 will dedup identical atoms regardless of names which helps in the case of templates with same underlying types. Even if the symbols corresponding...

...e size. This can't be achieved when the symbols is private external. >>> >>> If I understand you correctly, ld64 will deduplicate >>> std::vector<int>::push_back and std::vector<unsigned>::push_back, but it >>> will not deduplicate std::vector<HiddenClassA>::push_back and >>> std::vector<HiddenClassB>::push_back. Is that correct? Do you know why >>> it has that limitation? >> >> ld64 will dedup identical atoms regardless of names which helps in the case of templates with same underlying types. > > Even i...

I did a bit more digging for the auto hide problem. Here is my finding that prevent us from doing this by default in GlobalOpts 1. When a symbol is linkonce_odr hidden unnamed_addr, it emits both '.private_extern' and '.weak_def_can_be_hidden' asm directives on macho platform. There result of that is .private_extern will win so this is essentially linkonce_odr hidden. 2. ld64 does

Interesting. Now I understand the full picture. For MachO, linker is picking based on atoms so it picks the atom with more visibility which doesn’t have the constraint you mentioned. Let me do some more digging. Worst case I will add a different rule for MachO but it might be fine. Steven > On Feb 9, 2018, at 1:40 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: >