Since we don't execute the binary we don't have to, but I agree it would the right thing to do, as something else could depend on it during replay. I'll address this once I figure out what's causing the flakiness on Linux.
On Thu, Mar 21, 2019 at 1:32 AM Pavel Labath <pa...@labath.sk> wrote: > On 21/03/2019 05:08, Jonas Devlieghere via lldb-commits wrote: > > Author: jdevlieghere > > Date: Wed Mar 20 21:08:31 2019 > > New Revision: 356643 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=356643&view=rev > > Log: > > [Reproducers] Properly handle QEnvironment packets > > > > On Linux, a QEnvironment packet is sent for every environment variable. > > This breaks replay when the number of environment variables is different > > then during capture. The solution is to always reply with OK. > > > > Modified: > > lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test > > > lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp > > > > Modified: lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test > > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test?rev=356643&r1=356642&r2=356643&view=diff > > > ============================================================================== > > --- lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test (original) > > +++ lldb/trunk/lit/Reproducer/TestGDBRemoteRepro.test Wed Mar 20 > 21:08:31 2019 > > @@ -9,7 +9,7 @@ > > # RUN: rm -rf %t.repro > > # RUN: %clang %S/Inputs/simple.c -g -o %t.out > > # RUN: %lldb -x -b -s %S/Inputs/GDBRemoteCapture.in --capture > --capture-path %t.repro %t.out | FileCheck %s --check-prefix CHECK > --check-prefix CAPTURE > > -# RUN: %lldb --replay %t.repro | FileCheck %s --check-prefix CHECK > --check-prefix REPLAY > > +# RUN: env FOO=BAR %lldb --replay %t.repro | FileCheck %s > --check-prefix CHECK --check-prefix REPLAY > > > > # CHECK: Breakpoint 1 > > # CHECK: Process {{.*}} stopped > > > > Modified: > lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp > > URL: > http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp?rev=356643&r1=356642&r2=356643&view=diff > > > ============================================================================== > > --- > lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp > (original) > > +++ > lldb/trunk/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationReplayServer.cpp > Wed Mar 20 21:08:31 2019 > > @@ -107,6 +107,13 @@ GDBRemoteCommunicationReplayServer::GetP > > m_send_acks = false; > > } > > > > + // A QEnvironment packet is sent for every environment variable. If > the > > + // number of environment variables is different during replay, the > replies > > + // become out of sync. > > + if (packet.GetStringRef().find("QEnvironment") == 0) { > > + return SendRawPacketNoLock("$OK#9a", true); > > + } > > + > > Log > *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS)); > > while (!m_packet_history.empty()) { > > // Pop last packet from the history. > > @@ -122,6 +129,14 @@ GDBRemoteCommunicationReplayServer::GetP > > "GDBRemoteCommunicationReplayServer actual packet: > '{}'\n", > > packet.GetStringRef()); > > } > > + > > + // Ignore QEnvironment packets as they're handled earlier. > > + if (entry.packet.data.find("QEnvironment") == 1) { > > + assert(m_packet_history.back().type == > > + GDBRemoteCommunicationHistory::ePacketTypeRecv); > > + m_packet_history.pop_back(); > > + } > > + > > continue; > > } > > > > > > > > _______________________________________________ > > lldb-commits mailing list > > lldb-commits@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > > > It sounds like we should have an "environment provider" which captures > and reinstates the environment during record and replay respectively. >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
