[lldb-dev] Loading object file to target flash memory using vFlashWrite

[Greg Clayton via lldb-dev]

> On Jan 11, 2018, at 2:22 AM, Pavel Labath <labath at google.com> wrote:
> 
> On 10 January 2018 at 22:17, Owen Shaw via lldb-dev
> <lldb-dev at lists.llvm.org <mailto:lldb-dev at 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 <clayborg at gmail.com> wrote:
>>> 
>>> On Jan 9, 2018, at 4:32 PM, Owen Shaw <llvm at owenpshaw.net> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180111/3d0984de/attachment-0001.html>