- User Since
- Dec 12 2019, 11:43 AM (16 w, 3 d)
Thu, Mar 26
Yes, I managed to get a .debug_loc section also for Wasm with similar code, and debug_loc does not seem to present the same problems with GC'd functions.
Even without your patch? If without your patch you were getting range list entries of zero/zero, I'd expect you to get debug_loc entries with zero/zero too. Any ideas why it doesn't? They should be a similar pair of relocations (though it looks like your fix should work for debug_loc too, which is good).
Looking at the generated DWARF, this patch does not change the offsets for debug_loc. Like in the example above, there are loc entries for variables in the deleted function f2:
0x0000004a: DW_TAG_subprogram DW_AT_low_pc (0x0000000000000000) DW_AT_high_pc (0x000000000000004d) DW_AT_frame_base (DW_OP_WASM_location 0x0 +1, DW_OP_stack_value) DW_AT_GNU_all_call_sites (true) DW_AT_linkage_name ("_Z2f2Ri") DW_AT_name ("f2") DW_AT_decl_file ("C:\dev\llvm-project\release_x64\T\main.cc") DW_AT_decl_line (3) DW_AT_type (0x000000cd "int") DW_AT_external (true) [...] 0x00000071: DW_TAG_variable DW_AT_location (0x00000000: [0x00000014, 0x0000001b): DW_OP_consts +42, DW_OP_stack_value [0x00000026, 0x0000002d): DW_OP_consts +21, DW_OP_stack_value [0x0000003f, 0x0000004d): DW_OP_WASM_location 0x0 +2, DW_OP_stack_value) DW_AT_name ("i") DW_AT_decl_file ("C:\dev\llvm-project\release_x64\T\main.cc") DW_AT_decl_line (4) DW_AT_type (0x000000cd "int")
The entries seems to assume that the deleted function starts at offset 0, and ends at 0x4d, and this is true also without the patch.
Tue, Mar 24
Mon, Mar 23
@sbc100 Adding a test.
Sat, Mar 21
Thank you Sam, fixing this in calcNewValue also works and it's cleaner.
Feb 27 2020
Feb 26 2020
The Harbormaster errors don't seem to be real failures:
/mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/lldb/source/Core/Module.cpp:9:10: error: 'lldb/Core/Module.h' file not found [clang-diagnostic-error] #include "lldb/Core/Module.h" ^ /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/lldb/source/Target/Memory.cpp:9:10: error: 'lldb/Target/Memory.h' file not found [clang-diagnostic-error] #include "lldb/Target/Memory.h" ^
Feb 25 2020
Hi @paolosev, the lldb sanitized bot is flagging a container-overflow error here. I know that this /can/ have FPs when sanitized and unsanitized code is mixed, but we should be in purely sanitized code here, and this looks like a valid report. PTAL.
Feb 18 2020
Feb 17 2020
I think it depends on whether the DynamicLoaderStatic should be a fallback. If it doesn't make sense then yes, I think we should reject that triple there.
It should not be a fallback. Ok! I'll create a new patch with this change.
@JDevlieghere added inline comments:
What's the rationale here? Plugins shouldn't rely on the order in which they are initialized. This breaks when the initializers are auto generated. Can we remove this dependency?
Feb 14 2020
Feb 12 2020
Fix patch after rebasing:
- Use macros to initialize plugins in SystemInitializer.
- Move tests from /packages/Python/lldbsuite/test/functionalities/gdb_remote_client/ to /test/API/functionalities/gdb_remote_client/
Feb 7 2020
Feb 6 2020
Modified tests to be compatible with Python3.
Feb 5 2020
Thank you Derek, Jonas; I am sorry for all the trouble...
Fixing ObjectFile/wasm tests.
Feb 4 2020
Jan 31 2020
Fixed the tests as suggested, and also added a couple more tests, to cover both the case where the Wasm module is loaded from memory and the case where it is loaded from a file.
Jan 29 2020
- 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?
I am fine with 1 as long as we document the DynamicLoader class to say that it will call Process::LoadModules() and will be used if no specialized loader is needed for your platform. I would like to a see a solution that will work for any process plug-in and not just ProcessGDBRemote. If we change solution 3 above to say "Make lldb_private::Process call LoadModules() itself if no dynamic loader instance is available" then solution 3 is also fine.
Jan 27 2020
Jan 24 2020
Modified to set m_file_offset to be the correct offset of the Code section. This also simplifies the code in ObjectFileWasm to avoid a special case for the code section in ObjectFileWasm::SetLoadAddress.
The DWARF code seems to only use GetFileAddress(), which still needs to return zero for the Code section.
Jan 23 2020
Thanks for the explanation! I wasn't quite clear on "executable module" here, but after your comments I realized that Target::SetExecutableModule() should not probably be called also for Wasm modules.
The point is that ObjectFileWasm::CalculateType() should return eTypeSharedLibrary, not eTypeExecutable.
With this change the first issue is easily solved: we just need to call Target::SetSectionLoadAddress() once, in ObjectFileWasm::SetLoadAddress() because Target::SetExecutableModule() -> Target::ClearModules() -> SectionLoadList::Clear() is not called, and DynamicLoaderWasmDYLD::DidAttach() can be simplified to just call ProcessGDBRemote::LoadModules().
Does this solution work for you? If so, we should look at the second point, the need to initialize m_file_addr = m_file_offset = 0 for the "code" Section in order to make the DWARF symbols work...
Jan 22 2020
I have verified the logic of the dynamic loader quite carefully, but there are a couple of things to clarify.
Jan 15 2020
Modified test to have two "inlined" yaml files and use "yaml2obj --docnum".
Jan 14 2020
What is the best way to test this class?
Rebasing from D71575.
Added "lldb-test object-file" test.
Jan 13 2020
Jan 10 2020
I apologize for the noob question, but how do I schedule a build for this diff with Harbormaster?
Jan 8 2020
Jan 5 2020
Addressed more review comments:
- removed code to manage "external_debug_info" sections; logic for this will be implemented in the symbol vendor code.
- modified test code, from unittests to be Shell "lit" tests.
Jan 3 2020
Dec 20 2019
Doh! I didn't know there was this work ongoing.
I think we could maybe continue from there, once https://reviews.llvm.org/D70930 is merged; what I would like is to have something like --split-dwo that works with WASM files and only extracts DWARF sections.
Dec 18 2019
Dec 17 2019
Addressed first review comments.
Thanks for all the comments! I am updating the code following your suggestions.
Next step will be to split this into three distinct patches, as suggested by Pavel.