https://sourceware.org/bugzilla/show_bug.cgi?id=33577
--- Comment #25 from Ali Bahrami <ali_swbugzilla at emvision dot com> --- (In reply to Rui Ueyama from comment #23) > We essentially ignore all dynamic symbols with VER_NDX_LOCAL as if they > didn't exist in .dynsym at all. I don't exactly remember why we chose to do > that, but I believe that was my interpretation of "VER_NDX_LOCAL (0): symbol > has local scope". > Symbols with local scope are generally not visible from other files, so it > shouldn't be an unnatural interpretation of the sentence. I agree, it seems to follow from the documentation, which in hindsight seems a bit incomplete or ambiguous. At best, VER_NDX_LOCAL is derived information, based on the actual binding, which is in the symbol's st_info field. I think it would be better to key off that. You probably do, for objects that don't have a versym section (aren't versioned). Or do you not encounter non-versioned objects? > We can change mold so that it handles dynamic symbols with VER_NDX_LOCAL in > the same manner as GNU ld. That's probably a good idea because mold aims to > be as compatible with GNU ld as possible. That's probably a good idea for general correctness as well. Versioning augments the basic symbol, but isn't intended to contradict it. > > However, I'd like you guys to reevaluate the risk of introducing a major > compatibility problem with such short notice. It is likely to break many > user environments. When different implementations of a written spec make different interpretations like this, it can be hard to spot, and hard to fix, particularly when a lot of time passes. It seems that we've found another one of those. Had this been understood as a compatibility concern, we wouldn't have gone there, and now that we understand that it is, and how, I won't stand in the way of rolling it back. Perhaps it could be wrapped in an "#ifdef __sun" for now? The correctness of the GNU choice (assigning an undefined reference to a VERDEF index) is questionable, so this is entirely about not breaking existing tools. It would be nice and tidy if objects made for Solaris could follow our implementation. On the other hand, we seem to handle it either way, so I don't insist. -- You are receiving this mail because: You are on the CC list for the bug.
