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

[Pavel Labath via lldb-dev]

On 10 January 2018 at 22:17, Owen Shaw via lldb-dev
<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.