[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw updated this revision to Diff 137420.
owenpshaw added a comment.
- Revert changes to SetLoadAddress (always use virtual address there)
- Override LoadInMemory in ObjectFileELF to just load segments using physical
address instead of using section load list
Passes tests, but I don't have access to hardware this week to double check
that this works in the real world.
As an effect of this change, the "--load" part of "target modules load" now
ignores the other command arguments for setting section addresses (--slide
and/or the section/addr pairs). --slide would be easy to add back, but would
probably need to become an argument to LoadInMemory. Does anyone have a clear
sense of when someone would want to use --slide in combination with --load?
What about section/add pairs? Should the --load behavior instead be spun off
into a new command?
https://reviews.llvm.org/D42145
Files:
include/lldb/Host/XML.h
include/lldb/Target/MemoryRegionInfo.h
include/lldb/Target/Process.h
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestGDBRemoteLoad.py
packages/Python/lldbsuite/test/functionalities/gdb_remote_client/gdbclientutils.py
source/Host/common/XML.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/ObjectFile/ELF/ObjectFileELF.h
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
source/Symbol/ObjectFile.cpp
source/Target/Process.cpp
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -2533,6 +2533,17 @@
return 0;
}
+Status Process::WriteObjectFile(std::vector entries) {
+ Status error;
+ for (const auto &Entry : entries) {
+WriteMemory(Entry.Dest, Entry.Contents.data(), Entry.Contents.size(),
+error);
+if (!error.Success())
+ break;
+ }
+ return error;
+}
+
#define USE_ALLOCATE_MEMORY_CACHE 1
addr_t Process::AllocateMemory(size_t size, uint32_t permissions,
Status &error) {
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -659,22 +659,31 @@
SectionList *section_list = GetSectionList();
if (!section_list)
return Status("No section in object file");
+
+ std::vector writeEntries;
+
+ // Create a list of write entries from loadable sections
size_t section_count = section_list->GetNumSections(0);
for (size_t i = 0; i < section_count; ++i) {
+Process::WriteEntry entry;
SectionSP section_sp = section_list->GetSectionAtIndex(i);
-addr_t addr = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
-if (addr != LLDB_INVALID_ADDRESS) {
- DataExtractor section_data;
- // We can skip sections like bss
- if (section_sp->GetFileSize() == 0)
-continue;
- section_sp->GetSectionData(section_data);
- lldb::offset_t written = process->WriteMemory(
- addr, section_data.GetDataStart(), section_data.GetByteSize(), error);
- if (written != section_data.GetByteSize())
-return error;
-}
+entry.Dest = target.GetSectionLoadList().GetSectionLoadAddress(section_sp);
+if (entry.Dest == LLDB_INVALID_ADDRESS)
+ continue;
+// We can skip sections like bss
+if (section_sp->GetFileSize() == 0)
+ continue;
+DataExtractor section_data;
+section_sp->GetSectionData(section_data);
+entry.Contents = llvm::ArrayRef(section_data.GetDataStart(),
+ section_data.GetByteSize());
+writeEntries.push_back(entry);
}
+
+ error = process->WriteObjectFile(std::move(writeEntries));
+ if (!error.Success())
+return error;
+
if (set_pc) {
ThreadList &thread_list = process->GetThreadList();
ThreadSP curr_thread(thread_list.GetSelectedThread());
Index: source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -144,6 +144,8 @@
size_t DoReadMemory(lldb::addr_t addr, void *buf, size_t size,
Status &error) override;
+ Status WriteObjectFile(std::vector entries) override;
+
size_t DoWriteMemory(lldb::addr_t addr, const void *buf, size_t size,
Status &error) override;
@@ -302,6 +304,11 @@
int64_t m_breakpoint_pc_offset;
lldb::tid_t m_initial_tid; // The initial thread ID, given by stub on attach
+ bool m_allow_flash_writes;
+ using FlashRangeVector = lldb_private::RangeVector;
+ using FlashRange = FlashRangeVector::Entry;
+ FlashRangeVector m_erase
[Lldb-commits] [PATCH] D42145: [lldb] Use vFlash commands when writing to target's flash memory regions
owenpshaw reopened this revision. owenpshaw added a comment. Reopening since the previous land was reverted https://reviews.llvm.org/D42145 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r326919 - [lldbtestsuite] llvm-objcopy is now required to run the lit tests.
Author: davide Date: Wed Mar 7 10:06:12 2018 New Revision: 326919 URL: http://llvm.org/viewvc/llvm-project?rev=326919&view=rev Log: [lldbtestsuite] llvm-objcopy is now required to run the lit tests. There's now a test using llvm-objcopy in lit/. This doesn't fail on the bot(s) because `llvm-objcopy` is probably already available there, but if you get a fresh checkout and run `ninja check-lldb` you'll observe the failure as it's not tracking the dependency correctly. This fixes the problem on my machine, and probably everywhere else. Modified: lldb/trunk/lit/CMakeLists.txt Modified: lldb/trunk/lit/CMakeLists.txt URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/CMakeLists.txt?rev=326919&r1=326918&r2=326919&view=diff == --- lldb/trunk/lit/CMakeLists.txt (original) +++ lldb/trunk/lit/CMakeLists.txt Wed Mar 7 10:06:12 2018 @@ -41,6 +41,7 @@ set(LLDB_TEST_DEPS lldb lldb-test llvm-config + llvm-objcopy ) if(NOT LLDB_BUILT_STANDALONE) ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
On Fri, Feb 23, 2018 at 9:49 AM, Pavel Labath via lldb-commits wrote: > Author: labath > Date: Fri Feb 23 09:49:26 2018 > New Revision: 325927 > > URL: http://llvm.org/viewvc/llvm-project?rev=325927&view=rev > Log: > Replace HashStringUsingDJB with llvm::djbHash > > Summary: > The llvm function is equivalent to this one. Where possible I tried to > replace const char* with llvm::StringRef to avoid extra strlen > computations. In most places, I was able to track the c string back to > the ConstString it was created from. > > I also create a test that verifies we are able to lookup names with > unicode characters, as a bug in the llvm compiler (it accidentally used > a different hash function) meant this was not working until recently. > > This also removes the unused ExportTable class. > > Reviewers: aprantl, davide > The unicode test that you added fails for me (and others here) locally on MacOS. Session logs for test failures/errors/unexpected successes will go into directory '/Users/davide/work/llvm-monorepo/build/lldb-test-traces' Command invoked: /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 --executable /Users/davide/work/llvm-monorepo/build/bin/lldb -s /Users/davide/work/llvm-monorepo/build/lldb-test-traces --build-dir /Users/davide/work/llvm-monorepo/build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS -C /Users/davide/work/llvm-monorepo/build/./bin/clang --codesign-identity lldb_codesign --server /Users/davide/work/llvm-monorepo/build/bin/debugserver --results-port 51468 -S nm --inferior -p TestUnicodeSymbols.py /Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lang/c/unicode --event-add-entries worker_index=15:int FAIL: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) :: test_union_members_dsym (TestUnicodeSymbols.TestUnicodeSymbols) PASS: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) :: test_union_members_dwarf (TestUnicodeSymbols.TestUnicodeSymbols) PASS: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) :: test_union_members_gmodules (TestUnicodeSymbols.TestUnicodeSymbols) == FAIL: test_union_members_dsym (TestUnicodeSymbols.TestUnicodeSymbols) -- Traceback (most recent call last): File "/Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in dsym_test_method return attrvalue(self) File "/Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py", line 18, in test_union_members self.assertTrue(mytype.IsValid()) AssertionError: False is not True Config=x86_64-/Users/davide/work/llvm-monorepo/build/bin/clang-7.0 -- Ran 3 tests in 2.715s RESULT: FAILED (2 passes, 1 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes) [TestUnicodeSymbols.py FAILED] Any chance that you can take a look? It's a little weird because only the dsym version is actually failing. Thanks! -- Davide ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
The hashing algorithm gives different values - at least for foobár - between the two implementations. So if you build with an older clang, and test with a new lldb, the type lookup fails. Were the two algorithms supposed to be identical? It will mean that type lookups in the output of older clangs will start failing with the new lldb, which is not so great. Though to be honest, if it's only for high bit characters it isn't super critical... Jim > On Mar 7, 2018, at 5:43 PM, Davide Italiano via lldb-commits > wrote: > > On Fri, Feb 23, 2018 at 9:49 AM, Pavel Labath via lldb-commits > wrote: >> Author: labath >> Date: Fri Feb 23 09:49:26 2018 >> New Revision: 325927 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=325927&view=rev >> Log: >> Replace HashStringUsingDJB with llvm::djbHash >> >> Summary: >> The llvm function is equivalent to this one. Where possible I tried to >> replace const char* with llvm::StringRef to avoid extra strlen >> computations. In most places, I was able to track the c string back to >> the ConstString it was created from. >> >> I also create a test that verifies we are able to lookup names with >> unicode characters, as a bug in the llvm compiler (it accidentally used >> a different hash function) meant this was not working until recently. >> >> This also removes the unused ExportTable class. >> >> Reviewers: aprantl, davide >> > > The unicode test that you added fails for me (and others here) locally on > MacOS. > > Session logs for test failures/errors/unexpected successes will go > into directory '/Users/davide/work/llvm-monorepo/build/lldb-test-traces' > Command invoked: > /Users/davide/work/llvm-monorepo/llvm-project-20170507/llvm/tools/lldb/test/dotest.py > -q --arch=x86_64 --executable > /Users/davide/work/llvm-monorepo/build/bin/lldb -s > /Users/davide/work/llvm-monorepo/build/lldb-test-traces --build-dir > /Users/davide/work/llvm-monorepo/build/lldb-test-build.noindex -S nm > -u CXXFLAGS -u CFLAGS -C > /Users/davide/work/llvm-monorepo/build/./bin/clang --codesign-identity > lldb_codesign --server > /Users/davide/work/llvm-monorepo/build/bin/debugserver --results-port > 51468 -S nm --inferior -p TestUnicodeSymbols.py > /Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lang/c/unicode > --event-add-entries worker_index=15:int > FAIL: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) > :: test_union_members_dsym (TestUnicodeSymbols.TestUnicodeSymbols) > PASS: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) > :: test_union_members_dwarf (TestUnicodeSymbols.TestUnicodeSymbols) > PASS: LLDB (/Users/davide/work/llvm-monorepo/build/bin/clang-7.0-x86_64) > :: test_union_members_gmodules (TestUnicodeSymbols.TestUnicodeSymbols) > == > FAIL: test_union_members_dsym (TestUnicodeSymbols.TestUnicodeSymbols) > -- > Traceback (most recent call last): > File > "/Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lldbtest.py", > line 1769, in dsym_test_method > return attrvalue(self) > File > "/Users/davide/work/llvm-monorepo/llvm-project-20170507/lldb/packages/Python/lldbsuite/test/lang/c/unicode/TestUnicodeSymbols.py", > line 18, in test_union_members > self.assertTrue(mytype.IsValid()) > AssertionError: False is not True > Config=x86_64-/Users/davide/work/llvm-monorepo/build/bin/clang-7.0 > -- > Ran 3 tests in 2.715s > > RESULT: FAILED (2 passes, 1 failures, 0 errors, 0 skipped, 0 expected > failures, 0 unexpected successes) > > [TestUnicodeSymbols.py FAILED] > > Any chance that you can take a look? > It's a little weird because only the dsym version is actually failing. > > Thanks! > > -- > Davide > ___ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r325927 - Replace HashStringUsingDJB with llvm::djbHash
On Wed, Mar 7, 2018 at 6:39 PM, Jim Ingham wrote: > The hashing algorithm gives different values - at least for foobár - between > the two implementations. So if you build with an older clang, and test with > a new lldb, the type lookup fails. > This is not my case, I think? I'm building from the monorepo so clang and lldb are supposed to be in sync (in fact, the version of clang in my test is 7.0). Thanks, -- Davide ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
