labath wrote: > I realised that as it was, the calling object file would get its map updated > but not the other object file. Which is potentially a regression if we choose > to use one or the other file for a lookup. So now the methods update the > member map, and return the changes they made to it, so the caller can do the > same. > > But now I've done that I'm wondering why this map doesn't live in the symbol > table object itself, so I'm gonna try doing that.
While I do see some advantages to the other approach, I'm not convinced it is better overall. My reasons for that are: - The Symtab class is generic, while the approach of marking address types via fake symtab symbols is (I think) an elf invention. In fact, ObjectFileELF goes out of its way to make sure these fake symbols don't end up in the Symtab object for everyone to see, which makes it a bit strange to have that patch add them in via a back door. - The address class queries are currently done on the object file, and the address class computation is done on the object file as well. The symtab class has nothing to do with them, and just serves as an outsourced map storage for the object file. I don't think either of these are showstoppers, and I can live with the other approach if you feel strongly about it, but if it were up to me, I'd stick with this PR (you can put the map into both object files if you wish). https://github.com/llvm/llvm-project/pull/91585 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
