labath added a reviewer: jingham. labath added a subscriber: jingham. labath added a comment.
Thanks. My hopefully final question is not really for you but more like for other lldb developers (@jingham, @clayborg, etc.). Given that this plugin is now consisting of boiler plate only, I am wondering if we should not instead make it possible for this use case to work without any special plugins needed. A couple of options that come to mind are: - make the base DynamicLoader class instantiatable, and use it whenever we fail to find a specialized plugin - same as above, but only do that for ProcessGDBRemote instances - make ProcessGDBRemote call `LoadModules()` itself if no dynamic loader instance is available WDYT? In D72751#1843458 <https://reviews.llvm.org/D72751#1843458>, @paolosev wrote: > Yes, this seems to be the case with the current implementation of > ObjectFileWASM. It creates the section list in > `ObjectFileWasm::SetLoadAddress` which calls `Target::SetSectionLoadAddress` > but the sections don't need to be fully loaded, and during > `SymbolFileDWARF::CalculateAbilities(...)` `ObjectFile::ReadSectionData` is > called to load the necessary data. This is correct, but I want to point out that the "load" in SetLoadAddress and in ReadSectionData have two very different meanings. The first one records the address of a section in the process memory, while the second one "load" the contents of a section into lldb memory (from whereever). The second one should work regardless of whether the first one was called. This is why you are able to inspect the debug info of an executable before actually running it. > File addresses can uniquely identify a single section, there is no problem > with this, and there is always a single code section per module. The only > "weirdness" is that since DWARF code addresses for Wasm are calculated from > the beginning of the Code section, not the beginning of the file, for the > Code section, `Section::m_file_offset` can normally be the file offset, but > `Section::m_file_addr` needs to be zero. This seems to make all DWARF-related > code work, but, as Pavel said, maybe there could be places where LLDB expects > the "load bias" to be the same for each section, which could cause problems? The basic section loading machinery can handle sections which are "shuffled" around, but this is not true of everything (because this is not how typical object file formats work). Given that you only have one code section (no debug info or symbols should point into the debug sections) I think you should be mostly fine. In fact it would be possible to organize things such that the "load bias" is a constant, if we create an additional pseudo-section for the file header (like we do for COFF) with a negative file address. The layout would them look something like this /------------\ | header | file_addr = -sizeof(header) |------------| | code | file_addr = 0 |------------| | debug_info | file_addr = offsetof(debug_info) - sizeof(header) \------------/ This would keep the code section at address zero, and after applying a load bias of `module_id | sizeof(header)`, everything would land in the right place. The reason I haven't proposed that is because that gets a bit messy, and so it seems acceptable to just do what you do now, provided it ends up working. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72751/new/ https://reviews.llvm.org/D72751 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
