labath added a comment. In D55998#1341263 <https://reviews.llvm.org/D55998#1341263>, @joerg wrote:
> I foundamentally don't understand what you are trying to do. This is stemming from a discussion on a different patch. If you're interested in the full background you can look it up here https://reviews.llvm.org/D55356#1327099 (note that some of it happened on the mailing list, so it may not have made it into phabricator), but the short story is this: I needed a way to represent the base address of a module in lldb. Although that seems trivial, it is made complicated by the fact that lldb assumes that this address will belong to one of the module's sections. In the ELF case that typically won't be the case, as the load address will typically point to the first byte of the elf header (although it can point to anything really). Now, after learning this, my first reaction was also, "well, duh, we need to change that assumption", but then I realized that this will actually be correct if you consider treat segments to be "sections" as well (as then the load address is just the first byte of the first section). The nice part about this is that (to my surprise) perfectly matches what lldb is doing for MachO files. And if we assume that the elf spec that Jan quoted is true, then this is also a perfectly valid thing to do. Also, even though this wasn't my motivation, I believe an even bigger impact of this will be greater accuracy in the way lldb attributes addresses. Right now, if you ask lldb about an a module's address which doesn't belong to any of the module's sections (e.g. the inter-section padding, or the padding commonly present at the beginning of the first segment), then lldb will say it doesn't have a clue. With this patch, it will correctly report that this address belongs to the module and was loaded by the given PT_LOAD segment. > You can either look at the executable from a segment perspective or from a > section perspective. But trying to mix the views is bound to give bogus > results. But will it really? I mean, it's technically possible to create an elf file with inconsistent section/segment views, but the only way I know of doing that involves using a hex editor (and, then, I could create bogus MachO files the same way). As far as I know, gnu linker scripts https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_23.html#SEC23 only allow you to put the whole section into a segment or none of it. yaml2obj (I know that's not a very convincing data point) has the same restriction. With a hex-editor, I can create many inconsistencies using the section headers alone, but I'm not worried about those either, if there isn't a legitimate use case for e.g. sections with overlapping VM addresses. Obviously, throwing program headers into the mix adds a whole new level of possible inconsistencies, but I am not sure if these ever occur in practice. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55998/new/ https://reviews.llvm.org/D55998 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
