> On Jan 8, 2019, at 1:25 AM, Pavel Labath <pa...@labath.sk> 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 <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 <pa...@labath.sk >>>> <mailto:pa...@labath.sk><mailto:pa...@labath.sk>> 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 guaranteed to be unique everywhere. Of course, you >>>> cannot serialize that to a file, but since you already have a central >>>> place where you list all intercepted functions (to register their >>>> replayers), that place can be also used to assign unique integer IDs to >>>> these functions. So then the idea would be that the SB_RECORD macro >>>> takes the address of the current function, that gets converted to an ID >>>> in the lookup table, and the ID gets serialized. >>>> It sound like you would generate the indices at run-time. How would that >>>> work with regards to the the reverse mapping? >>> In the current implementation, SBReplayer::Init contains a list of all >>> intercepted methods, right? Each of the SB_REGISTER calls takes two >>> arguments: The method name, and the replay implementation. >>> >>> I would change that so that this macro takes three arguments: >>> - the function address (the "runtime" ID) >>> - an integer (the "serialized" ID) >>> - the replay implementation >>> >>> This creates a link between the function address and the serialized ID. So >>> when, during capture, a method calls SB_RECORD_ENTRY and passes in the >>> function address, that address can be looked up and translated to an ID for >>> serialization. >>> >>> The only thing that would need to be changed is to have SBReplayer::Init >>> execute during record too (which probably means it shouldn't be called >>> SBReplayer, but whatever..), so that the ID mapping is also available when >>> capturing. >>> >>> Does that make sense? >> I think I understand what you’re explaining, and the mapping side of things >> makes sense. But I’m concerned about the size and complexity of the >> SB_RECORD macro that will need to be written. IIUC, those would need to take >> the address of the current function and the prototype, which is a lot of >> cumbersome text to type. It seems like having a specialized tool to generate >> those would be nice, but once you have a tool you also don’t need all this >> complexity, do you? >> Fred > > Yes, if the tool generates the IDs for you and checks that the macro > invocations are correct, then you don't need the function prototype. However, > that tool also doesn't come for free: Somebody has to write it, and it adds > complexity in the form of an extra step in the build process.
Definitely agreed, the complexity has to be somewhere. > My point is that this extended macro could provide all the error-checking > benefits of this tool. It's a tradeoff, of course, and the cost here is a > more complex macro invocation. I think the choice here is mostly down to > personal preference of whoever implements this. However, if I was > implementing this, I'd go for an extended macro, because I don't find the > extra macro complexity to be too much. For example, this should be the macro > invocation for SBData::SetDataFromDoubleArray: > > SB_RECORD(bool, SBData, SetDataFromDoubleArray, (double *, size_t), > array, array_len); Yeah, this doesn’t seem so bad. For some reason I imagined it much more verbose. Note that a verification tool that checks that every SB method is instrumented correctly would still be nice (but it can come as a follow-up). > It's a bit long, but it's not that hard to type, and all of this information > should be present on the previous line, where SBData::SetDataFromDoubleArray > is defined (I deliberately made the macro argument order match the function > definition syntax). > > And this approach can be further tweaked. For instance, if we're willing to > take the hit of having "weird" function definitions, then we can avoid the > repetition altogether, and make the macro define the function too: > > SB_METHOD2(bool, SBData, SetDataFromDoubleArray, double *, array, > size_t, array_len, { > // Method body > }) I personally don’t like this. Fred > This would also enable you to automatically capture method return value for > the "object" results. > > pl _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev