This is an archive of the discontinued LLVM Phabricator instance.

[Reproducers] Add SBReproducer macros
ClosedPublic

Authored by JDevlieghere on Jan 30 2019, 2:39 PM.

Details

Summary

This patch adds the SBReproducer macros needed to capture and reply the corresponding calls.

The patch was generated using the SBRepro tool (D56822).

Diff Detail

Event Timeline

JDevlieghere created this revision.Jan 30 2019, 2:39 PM

BTW, it would be nice to mention somewhere how to use this tool. Do you just run it, or does it needs some special arguments, or something?

source/API/SBBlock.cpp
52–58

It looks like some functions have a newline after the macro, and some don't. What's the reason for that?

JDevlieghere marked an inline comment as done.Jan 31 2019, 10:29 AM
JDevlieghere added inline comments.
source/API/SBBlock.cpp
52–58

It depends on whether there was a newline before or not. So

foo { bar }

will not have the newline, while

foo {
bar;
}

This happens because we insert the macro at the first loc, before the potentially existing \n. Getting this right for all cases and coding styles is tricky, so the tool doesn't try to get it right. It just inserts it there and relies on clang-format to fix the formatting.

labath added inline comments.Jan 31 2019, 11:04 AM
source/API/SBBlock.cpp
52–58

Aha. That's funny.

How about changing to tool to always add *two* newlines after the macro invocation? clang-format removes multiple empty lines, so if this results in creates them, clang-format should always coalesce into one.

  • Rebase
  • Re-ran the latest version of the tool to insert LLDB_RECORD_RESULT
labath accepted this revision.Feb 18 2019, 11:09 PM

lgtm

This revision is now accepted and ready to land.Feb 18 2019, 11:09 PM
This revision was automatically updated to reflect the committed changes.

Run into a few compilation errors building on Windows with msvc.

source/API/SBReproducer.cpp
40

Array size must be compile-time constant.

1120

lldb::thread_t is just a void* on Windows, so

return new UnderlyingT(Deserialize<UnderlyingT>());

tries to allocate void object.

JDevlieghere marked 4 inline comments as done.Mar 6 2019, 8:42 AM

Thanks Tatyana!

source/API/SBReproducer.cpp
40

Fixed in rL355518

1120

Fixed in rL355519.

mgorny added a subscriber: mgorny.Mar 6 2019, 11:15 PM

This is still breaking NetBSD buildbot: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/19339/steps/ninja%20build%20local/logs/stdio

FAILED: tools/lldb/source/API/CMakeFiles/liblldb.dir/SBHostOS.cpp.o 
/usr/bin/g++  -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLIBXML2_DEFINED -DLLDB_CONFIGURATION_RELEASE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/API -I/home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/API -Itools/lldb/include -I/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include -Iinclude -I/home/motus/netbsd8/netbsd8/llvm/include -I/usr/pkg/include/python2.7 -I/home/motus/netbsd8/netbsd8/llvm/tools/clang/include -Itools/lldb/../clang/include -I/usr/pkg/include/libxml2 -I/home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/. -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -DNDEBUG -fPIC    -fno-exceptions -fno-rtti -MD -MT tools/lldb/source/API/CMakeFiles/liblldb.dir/SBHostOS.cpp.o -MF tools/lldb/source/API/CMakeFiles/liblldb.dir/SBHostOS.cpp.o.d -o tools/lldb/source/API/CMakeFiles/liblldb.dir/SBHostOS.cpp.o -c /home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/API/SBHostOS.cpp
In file included from /home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/API/SBReproducerPrivate.h:18:0,
                 from /home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/API/SBHostOS.cpp:13:
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include/lldb/Utility/ReproducerInstrumentation.h: In instantiation of 'void lldb_private::repro::Serializer::Serialize(T&) [with T = __pthread_st]':
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include/lldb/Utility/ReproducerInstrumentation.h:518:7:   required from 'void lldb_private::repro::Serializer::Serialize(T*) [with T = __pthread_st]'
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include/lldb/Utility/ReproducerInstrumentation.h:506:5:   required from 'void lldb_private::repro::Serializer::SerializeAll(const Head&, const Tail& ...) [with Head = __pthread_st*; Tail = {lldb::SBError*}]'
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include/lldb/Utility/ReproducerInstrumentation.h:601:5:   required from 'void lldb_private::repro::Recorder::Record(Result (*)(FArgs ...), const RArgs& ...) [with Result = bool; FArgs = {__pthread_st*, lldb::SBError*}; RArgs = {__pthread_st*, lldb::SBError*}]'
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/source/API/SBHostOS.cpp:135:3:   required from here
/home/motus/netbsd8/netbsd8/llvm/tools/lldb/include/lldb/Utility/ReproducerInstrumentation.h:530:64: error: invalid application of 'sizeof' to incomplete type '__pthread_st'
       m_stream.write(reinterpret_cast<const char *>(&t), sizeof(T));
                                                                ^

It looks like it's trying to serialize opaque types.

Jonas, would it be possible to just not intercept the functions which work with thread IDs and similar stuff (an all OSs)?
Using the naive serialization approach will not be correct for these, even if the types happen to be implemented as primitive types (most likely we will need some runtime remapping of thread id's or something), so I am hoping it would not affect the ability to record&replay the recordings which don't use these functions.