Re: [lldb-dev] [Reproducers] SBReproducer RFC

Thank you for the update Jonas. I haven't looked at the patch in detail, but (for better or worse) it seems more-or-less like what I would expect at a first glance. One of the things that occurred to me while looking at this is that it would be great to be able to test this code in greater iso

Re: [lldb-dev] [Reproducers] SBReproducer RFC

I've put up a (WIP) patch for the tool (https://reviews.llvm.org/D56822) in case anybody is curious about that. On Tue, Jan 15, 2019 at 1:41 PM Jonas Devlieghere wrote: > I've updated the patch with a new version of the prototype: > https://reviews.llvm.org/D56322 > > It uses Pavel's suggestion

Re: [lldb-dev] [Reproducers] SBReproducer RFC

I've updated the patch with a new version of the prototype: https://reviews.llvm.org/D56322 It uses Pavel's suggestion to use the function address as a runtime ID. All the deserialization code is generated using templates, with automatic mapping on indices during serialization and deserialization.

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Wed, Jan 9, 2019 at 8:42 AM Pavel Labath wrote: > On 09/01/2019 17:15, Jonas Devlieghere wrote: > > > > > > On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath > > wrote: > > > > On 08/01/2019 21:57, Jonas Devlieghere wrote: > > > Before I got around to coding this up

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 09/01/2019 17:15, Jonas Devlieghere wrote: On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath > wrote: On 08/01/2019 21:57, Jonas Devlieghere wrote: > Before I got around to coding this up I realized you can't take the > address of constructors in C++, so the

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Wed, Jan 9, 2019 at 5:05 AM Pavel Labath wrote: > On 08/01/2019 21:57, Jonas Devlieghere wrote: > > Before I got around to coding this up I realized you can't take the > > address of constructors in C++, so the function address won't work as an > > identifier. > > > > You gave up way too easil

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 08/01/2019 21:57, Jonas Devlieghere wrote: Before I got around to coding this up I realized you can't take the address of constructors in C++, so the function address won't work as an identifier. You gave up way too easily. :P I realized that constructors are going to be tricky, but I di

Re: [lldb-dev] [Reproducers] SBReproducer RFC

Before I got around to coding this up I realized you can't take the address of constructors in C++, so the function address won't work as an identifier. On Tue, Jan 8, 2019 at 9:28 AM Jonas Devlieghere wrote: > On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss wrote: > >> >> >> > On Jan 8, 2019, at

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Tue, Jan 8, 2019 at 8:27 AM Frédéric Riss wrote: > > > > On Jan 8, 2019, at 1:25 AM, Pavel Labath wrote: > > > > On 07/01/2019 22:45, Frédéric Riss wrote: > >>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev < > lldb-dev@lists.llvm.org > wrote: > >>> >

Re: [lldb-dev] [Reproducers] SBReproducer RFC

> On Jan 8, 2019, at 1:25 AM, Pavel Labath wrote: > > On 07/01/2019 22:45, Frédéric Riss wrote: >>> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev >>> mailto:lldb-dev@lists.llvm.org>> wrote: >>> >>> On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pave

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 22:13, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 3:52 AM Tamas Berghammer > wrote: One problem is when the behavior of LLDB is not deterministic for whatever reason (e.g. multi threading, unordered maps, etc...). Lets take SBModul

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 22:45, Frédéric Riss wrote: On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev mailto:lldb-dev@lists.llvm.org>> wrote: On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > wrote:    I've

Re: [lldb-dev] [Reproducers] SBReproducer RFC

> On Jan 7, 2019, at 11:31 AM, Pavel Labath via lldb-dev > wrote: > > On 07/01/2019 19:26, Jonas Devlieghere wrote: >> On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > >> >> wrote: >>I've been thinking about how could t

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Mon, Jan 7, 2019 at 3:52 AM Tamas Berghammer wrote: > Thanks Pavel for looping me in. I haven't looked into the actual > implementation of the prototype yet but reading your description I have > some concern regarding the amount of data you capture as I feel it isn't > sufficient to reproduce

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 07/01/2019 19:26, Jonas Devlieghere wrote: On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath > wrote: I've been thinking about how could this be done better, and the best (though not ideal) way I came up with is using the functions address as the key. That's gu

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On Mon, Jan 7, 2019 at 1:40 AM Pavel Labath wrote: > On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: > > Hi Everyone, > > > > In September I sent out an RFC [1] about adding reproducers to LLDB. > > Over the > > past few months, I landed the reproducer framework, support for the GDB >

Re: [lldb-dev] [Reproducers] SBReproducer RFC

Thanks Pavel for looping me in. I haven't looked into the actual implementation of the prototype yet but reading your description I have some concern regarding the amount of data you capture as I feel it isn't sufficient to reproduce a set of usecases. One problem is when the behavior of LLDB is n

Re: [lldb-dev] [Reproducers] SBReproducer RFC

On 04/01/2019 22:19, Jonas Devlieghere via lldb-dev wrote: Hi Everyone, In September I sent out an RFC [1] about adding reproducers to LLDB. Over the past few months, I landed the reproducer framework, support for the GDB remote protocol and a bunch of preparatory changes. There's still an ope

[lldb-dev] [Reproducers] SBReproducer RFC

Hi Everyone, In September I sent out an RFC [1] about adding reproducers to LLDB. Over the past few months, I landed the reproducer framework, support for the GDB remote protocol and a bunch of preparatory changes. There's still an open code review [2] for dealing with files, but that one is curre