clayborg added a comment. In D131705#3726248 <https://reviews.llvm.org/D131705#3726248>, @labath wrote:
> I have somewhat mixed feelings about this. > > On one hand, I was never too happy with how we're creating these funny extra > sections, so I can't say I would be sad to see that go. OTOH, I can't really > agree with the assertion that these symbols do not represent "addresses". > All the ELF spec says about them is that they are not subject to relocation. > That makes them rather ill-suited for describing the locations of objects in > the usual scenarios. However, these symbols can be (and, I believe, are) used > in the embedded world for describing objects that are architecturally defined > to reside at a particular memory address (the 16-bit dos/bios world was full > of those). However, one can imagine something similar being done in userspace > as well (for example, if the kernel provides some data at a fixed virtual > address). We envisioned something similar when we added support for this. In > our case, the object/function in question was generated by a JIT, which knew > the exact address at which it placed the jitted code. I am fine trying to see if these symbols exist within an existing section and if they do, then resolve the symbol as a section + offset within an existing section value if you think that is the way to go. If they don't exist in any sections, then do what I am doing by just making them have no section. But really, why would you ever use a SHN_ABS symbol when you can make a real symbol that _is_ defined to be in a section? That is what puzzled me. The documentation in the ELF was not helpful, as you stated it just says these symbols have no relocations. but if you do have such a symbol, then if the section it does exist in does get relocated or moved at runtime, what good is the symbol and why not create an actual symbol in an actual section? > However, AFAIK, that project never materialized, and we are not relying on > these symbols for that. Tagging @dsrbecky to confirm. Assuming that's the > case, and given that gdb does not handle these symbols in this way either (at > least, I haven't been able to make it do that), I think we can go forward > with removing them. When you say "we can go forward with removing them", do you mean not add them at all as symbols? I wouldn't want to remove a symbol, I would rather keep it like I have added it now if possible. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131705/new/ https://reviews.llvm.org/D131705 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
