Re: [lldb-dev] Loading object file to target flash memory using vFlashWrite
On 10 January 2018 at 22:17, Owen Shaw via lldb-dev wrote: > Thanks! > > ObjectFileELF::SetLoadAddress(...) is where I already have a change > that got things working, just wasn't sure if I'd be stepping on > anything else that relied on the values set there. > > Looks like I dropped the dev list in my last message. Adding it back > so this is captured. > > On Wed, Jan 10, 2018 at 1:30 PM, Greg Clayton wrote: >> >> On Jan 9, 2018, at 4:32 PM, Owen Shaw wrote: >> >> Thanks! No problem doing one patch, totally get the reason...thought >> it be be easier to review in pieces, but it's not very much even with >> everything in. >> >> I'll work on figuring out the tests before submitting. Seems like >> most lldb tests are python, but I feel like these would fall in the >> c++ unit tests instead since there's no python API for them. Is that >> correct? >> >> >> There are many lldb-server tests around. I would try to do what those tests >> are doing. I'm not sure the existing lldb-server tests will be of much help here. What the existing tests do is *test the server* by driving it with a *specialized client* which verifies the server behavior. If I understand correctly, here you would want to *test the client* behavior when communicating with a *custom server*. Right now we don't have any tests of this sort, although it would be very good to have them -- we get patches to support all kinds of remote stubs, but we have no way to verify that the next patch does not break any previous ones. The low level details can be tested with a gdbremotecommunicationclient unit tests (like you did with the previous patch), but I don't think there is anything that would capture interactions at a slightly higher level. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Loading object file to target flash memory using vFlashWrite
> On Jan 11, 2018, at 2:22 AM, Pavel Labath wrote: > > On 10 January 2018 at 22:17, Owen Shaw via lldb-dev > mailto:lldb-dev@lists.llvm.org>> wrote: >> Thanks! >> >> ObjectFileELF::SetLoadAddress(...) is where I already have a change >> that got things working, just wasn't sure if I'd be stepping on >> anything else that relied on the values set there. >> >> Looks like I dropped the dev list in my last message. Adding it back >> so this is captured. >> >> On Wed, Jan 10, 2018 at 1:30 PM, Greg Clayton wrote: >>> >>> On Jan 9, 2018, at 4:32 PM, Owen Shaw wrote: >>> >>> Thanks! No problem doing one patch, totally get the reason...thought >>> it be be easier to review in pieces, but it's not very much even with >>> everything in. >>> >>> I'll work on figuring out the tests before submitting. Seems like >>> most lldb tests are python, but I feel like these would fall in the >>> c++ unit tests instead since there's no python API for them. Is that >>> correct? >>> >>> >>> There are many lldb-server tests around. I would try to do what those tests >>> are doing. > > I'm not sure the existing lldb-server tests will be of much help here. > What the existing tests do is *test the server* by driving it with a > *specialized client* which verifies the server behavior. If I > understand correctly, here you would want to *test the client* > behavior when communicating with a *custom server*. Right now we don't > have any tests of this sort, although it would be very good to have > them -- we get patches to support all kinds of remote stubs, but we > have no way to verify that the next patch does not break any previous > ones. The low level details can be tested with a > gdbremotecommunicationclient unit tests (like you did with the > previous patch), but I don't think there is anything that would > capture interactions at a slightly higher level. I think the best we can hope for is to mimic the packets that work with a client that supports the flash write packets.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 35920] New: Assertion failed: (OldTInfo && "substituting function without type source info")
https://bugs.llvm.org/show_bug.cgi?id=35920 Bug ID: 35920 Summary: Assertion failed: (OldTInfo && "substituting function without type source info") Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: v...@apple.com CC: llvm-b...@lists.llvm.org Bot failure: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-xcode/4101/ Command invoked: test/dotest.py --executable /Users/buildslave/jenkins/workspace/lldb-xcode/lldb/build/Release/lldb -C /Users/buildslave/jenkins/workspace/lldb-xcode/host-compiler/bin/clang --arch x86_64 --session-file-format fm --rerun-all-issues --env TERM=vt100 -s 2018-01-11-09_34_09 --results-port 59606 -S fm --inferior -p TestFunctionTemplateParameterPack.py /Users/buildslave/jenkins/workspace/lldb-xcode/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=1:int Configuration: arch=x86_64 compiler=/Users/buildslave/jenkins/workspace/lldb-xcode/host-compiler/bin/clang-7.0 -- Collected 3 tests Assertion failed: (OldTInfo && "substituting function without type source info"), function SubstFunctionType, file /Users/buildslave/jenkins/workspace/lldb-xcode/lldb/llvm/tools/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp, line 3418. [TestFunctionTemplateParameterPack.py FAILED] -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
