labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
In D131705#3726772 <https://reviews.llvm.org/D131705#3726772>, @clayborg wrote: > 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? I think that the reason this doesn't make sense is that the initial assumption (every symbol must reside in a section) is incorrect. That needs to be true if you want to relocate symbols, as relocation works on the level of sections. However, if the symbols value is not supposed to be affected by relocations, then it doesn't make sense for it to be in any particular section -- that's why elf introduces the special SHN_ABS "section" index. After everything is relocated and loaded into memory, it may end up pointing to some loaded section (as known to the tooling), or it may not. It does not make sense to ask the question "what happens if the section the symbol is in is relocated" because the symbol creator explicitly said it does not want the symbols value to be affected by relocation nor for them to be associated with any particular section. The reason why we introduced these fake sections is that lldb also assumed (and I don't really blame it) that every resolvable address must belong to a section, and we wanted to be able to resolve address that are described by these symbols. However, I have now confirmed that this functionality is not used (and I suspect the reason was that other tools were having problems understanding this as well), so I think it's fine to remove it. >> 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. I meant removing the extra fake sections. I agree that keeping the symbols is desirable. 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
