2018-10-18 11:57:19 +02:00
|
|
|
/****************************************************************************
|
|
|
|
|
**
|
|
|
|
|
** Copyright (C) 2018 The Qt Company Ltd.
|
|
|
|
|
** Contact: https://www.qt.io/licensing/
|
|
|
|
|
**
|
|
|
|
|
** This file is part of Qt Creator.
|
|
|
|
|
**
|
|
|
|
|
** Commercial License Usage
|
|
|
|
|
** Licensees holding valid commercial Qt licenses may use this file in
|
|
|
|
|
** accordance with the commercial license agreement provided with the
|
|
|
|
|
** Software or, alternatively, in accordance with the terms contained in
|
|
|
|
|
** a written agreement between you and The Qt Company. For licensing terms
|
|
|
|
|
** and conditions see https://www.qt.io/terms-conditions. For further
|
|
|
|
|
** information use the contact form at https://www.qt.io/contact-us.
|
|
|
|
|
**
|
|
|
|
|
** GNU General Public License Usage
|
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU
|
|
|
|
|
** General Public License version 3 as published by the Free Software
|
|
|
|
|
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
|
|
|
|
|
** included in the packaging of this file. Please review the following
|
|
|
|
|
** information to ensure the GNU General Public License requirements will
|
|
|
|
|
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
|
|
|
|
|
**
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
|
|
|
|
#include "perfdatareader.h"
|
|
|
|
|
#include "perfprofilerconstants.h"
|
|
|
|
|
#include "perfprofilerruncontrol.h"
|
|
|
|
|
#include "perfprofilertool.h"
|
|
|
|
|
#include "perfrunconfigurationaspect.h"
|
|
|
|
|
#include "perfsettings.h"
|
|
|
|
|
|
|
|
|
|
#include <coreplugin/icore.h>
|
|
|
|
|
#include <coreplugin/messagemanager.h>
|
|
|
|
|
#include <projectexplorer/devicesupport/deviceprocess.h>
|
|
|
|
|
#include <projectexplorer/devicesupport/idevice.h>
|
|
|
|
|
#include <projectexplorer/kitinformation.h>
|
|
|
|
|
#include <projectexplorer/target.h>
|
|
|
|
|
#include <ssh/sshconnection.h>
|
|
|
|
|
#include <utils/qtcprocess.h>
|
|
|
|
|
|
|
|
|
|
#include <QAction>
|
|
|
|
|
#include <QMessageBox>
|
|
|
|
|
#include <QTcpServer>
|
|
|
|
|
|
|
|
|
|
using namespace ProjectExplorer;
|
|
|
|
|
using namespace Utils;
|
|
|
|
|
|
|
|
|
|
namespace PerfProfiler {
|
|
|
|
|
namespace Internal {
|
|
|
|
|
|
|
|
|
|
class PerfParserWorker : public RunWorker
|
|
|
|
|
{
|
|
|
|
|
Q_OBJECT
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
PerfParserWorker(RunControl *runControl)
|
|
|
|
|
: RunWorker(runControl)
|
|
|
|
|
{
|
|
|
|
|
setId("PerfParser");
|
|
|
|
|
|
|
|
|
|
auto tool = PerfProfilerTool::instance();
|
|
|
|
|
m_reader.setTraceManager(tool->traceManager());
|
|
|
|
|
m_reader.triggerRecordingStateChange(tool->isRecording());
|
|
|
|
|
|
|
|
|
|
connect(tool, &PerfProfilerTool::recordingChanged,
|
|
|
|
|
&m_reader, &PerfDataReader::triggerRecordingStateChange);
|
|
|
|
|
|
|
|
|
|
connect(&m_reader, &PerfDataReader::updateTimestamps,
|
|
|
|
|
tool, &PerfProfilerTool::updateTime);
|
|
|
|
|
connect(&m_reader, &PerfDataReader::starting,
|
|
|
|
|
tool, &PerfProfilerTool::startLoading);
|
|
|
|
|
connect(&m_reader, &PerfDataReader::started, tool, &PerfProfilerTool::onReaderStarted);
|
|
|
|
|
connect(&m_reader, &PerfDataReader::finishing, this, [tool] {
|
|
|
|
|
// Temporarily disable buttons.
|
|
|
|
|
tool->setToolActionsEnabled(false);
|
|
|
|
|
});
|
|
|
|
|
connect(&m_reader, &PerfDataReader::finished, tool, &PerfProfilerTool::onReaderFinished);
|
|
|
|
|
|
|
|
|
|
connect(&m_reader, &PerfDataReader::processStarted, this, &RunWorker::reportStarted);
|
|
|
|
|
connect(&m_reader, &PerfDataReader::processFinished, this, &RunWorker::reportStopped);
|
|
|
|
|
connect(&m_reader, &PerfDataReader::processFailed, this, &RunWorker::reportFailure);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void start() override
|
|
|
|
|
{
|
Avoid some visible uses of RunControl::runConfiguration()
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-03-11 15:42:43 +01:00
|
|
|
QStringList args = m_reader.findTargetArguments(runControl());
|
2018-10-18 11:57:19 +02:00
|
|
|
QUrl url = runControl()->property("PerfConnection").toUrl();
|
|
|
|
|
if (url.isValid()) {
|
|
|
|
|
args.append(QStringList{"--host", url.host(), "--port", QString::number(url.port())});
|
|
|
|
|
}
|
2021-01-13 15:00:15 +01:00
|
|
|
appendMessage("PerfParser args: " + args.join(' '), Utils::NormalMessageFormat);
|
2018-10-18 11:57:19 +02:00
|
|
|
m_reader.createParser(args);
|
|
|
|
|
m_reader.startParser();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void stop() override
|
|
|
|
|
{
|
|
|
|
|
m_reader.stopParser();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PerfDataReader *reader() { return &m_reader;}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
PerfDataReader m_reader;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
class LocalPerfRecordWorker : public RunWorker
|
|
|
|
|
{
|
|
|
|
|
Q_OBJECT
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
LocalPerfRecordWorker(RunControl *runControl)
|
|
|
|
|
: RunWorker(runControl)
|
|
|
|
|
{
|
|
|
|
|
setId("LocalPerfRecordWorker");
|
|
|
|
|
|
Avoid some visible uses of RunControl::runConfiguration()
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-03-11 15:42:43 +01:00
|
|
|
auto perfAspect = static_cast<PerfRunConfigurationAspect *>(runControl->aspect(Constants::PerfSettingsId));
|
2018-10-18 11:57:19 +02:00
|
|
|
QTC_ASSERT(perfAspect, return);
|
|
|
|
|
PerfSettings *settings = static_cast<PerfSettings *>(perfAspect->currentSettings());
|
|
|
|
|
QTC_ASSERT(settings, return);
|
|
|
|
|
m_perfRecordArguments = settings->perfRecordArguments();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void start() override
|
|
|
|
|
{
|
|
|
|
|
m_process = device()->createProcess(this);
|
|
|
|
|
if (!m_process) {
|
|
|
|
|
reportFailure(tr("Could not start device process."));
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
connect(m_process, &DeviceProcess::started, this, &RunWorker::reportStarted);
|
|
|
|
|
connect(m_process, &DeviceProcess::finished, this, &RunWorker::reportStopped);
|
2022-01-27 10:55:39 +01:00
|
|
|
connect(m_process, &DeviceProcess::errorOccurred, [this](QProcess::ProcessError e) {
|
2018-10-18 11:57:19 +02:00
|
|
|
// The terminate() below will frequently lead to QProcess::Crashed. We're not interested
|
|
|
|
|
// in that. FailedToStart is the only actual failure.
|
|
|
|
|
if (e == QProcess::FailedToStart) {
|
2019-03-01 16:58:35 +01:00
|
|
|
QString msg = tr("Perf Process Failed to Start");
|
2020-06-02 09:10:40 +02:00
|
|
|
QMessageBox::warning(Core::ICore::dialogParent(),
|
2019-03-01 16:58:35 +01:00
|
|
|
msg, tr("Make sure that you are running a recent Linux kernel and "
|
|
|
|
|
"that the \"perf\" utility is available."));
|
2018-10-18 11:57:19 +02:00
|
|
|
reportFailure(msg);
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
Runnable perfRunnable = runnable();
|
|
|
|
|
|
|
|
|
|
QStringList arguments;
|
|
|
|
|
arguments << "record";
|
|
|
|
|
arguments += m_perfRecordArguments;
|
2021-08-10 09:19:30 +02:00
|
|
|
arguments << "-o" << "-" << "--" << perfRunnable.command.executable().toString()
|
|
|
|
|
<< ProcessArgs::splitArgs(perfRunnable.command.arguments(), OsTypeLinux);
|
2018-10-18 11:57:19 +02:00
|
|
|
|
2021-08-10 16:19:02 +02:00
|
|
|
perfRunnable.command.setExecutable("perf");
|
2021-08-10 09:19:30 +02:00
|
|
|
perfRunnable.command.setArguments(ProcessArgs::joinArgs(arguments, OsTypeLinux));
|
2018-10-18 11:57:19 +02:00
|
|
|
m_process->start(perfRunnable);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void stop() override
|
|
|
|
|
{
|
|
|
|
|
if (m_process)
|
|
|
|
|
m_process->terminate();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DeviceProcess *recorder() { return m_process; }
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
QPointer<DeviceProcess> m_process;
|
|
|
|
|
QStringList m_perfRecordArguments;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PerfProfilerRunner::PerfProfilerRunner(RunControl *runControl)
|
|
|
|
|
: RunWorker(runControl)
|
|
|
|
|
{
|
|
|
|
|
setId("PerfProfilerRunner");
|
|
|
|
|
|
|
|
|
|
m_perfParserWorker = new PerfParserWorker(runControl);
|
|
|
|
|
addStopDependency(m_perfParserWorker);
|
|
|
|
|
|
|
|
|
|
// If the parser is gone, there is no point in going on.
|
|
|
|
|
m_perfParserWorker->setEssential(true);
|
|
|
|
|
|
ProjectExplorer: Standardize RunWorker creation logic
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-08-23 15:31:35 +02:00
|
|
|
if ((m_perfRecordWorker = runControl->createWorker("PerfRecorder"))) {
|
2018-10-18 11:57:19 +02:00
|
|
|
m_perfParserWorker->addStartDependency(m_perfRecordWorker);
|
|
|
|
|
addStartDependency(m_perfParserWorker);
|
ProjectExplorer: Standardize RunWorker creation logic
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-08-23 15:31:35 +02:00
|
|
|
|
2018-10-18 11:57:19 +02:00
|
|
|
} else {
|
|
|
|
|
m_perfRecordWorker = new LocalPerfRecordWorker(runControl);
|
|
|
|
|
|
|
|
|
|
m_perfRecordWorker->addStartDependency(m_perfParserWorker);
|
|
|
|
|
addStartDependency(m_perfRecordWorker);
|
|
|
|
|
|
|
|
|
|
// In the local case, the parser won't automatically stop when the recorder does. So we need
|
|
|
|
|
// to mark the recorder as essential, too.
|
|
|
|
|
m_perfRecordWorker->setEssential(true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_perfParserWorker->addStopDependency(m_perfRecordWorker);
|
|
|
|
|
PerfProfilerTool::instance()->onWorkerCreation(runControl);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void PerfProfilerRunner::start()
|
|
|
|
|
{
|
|
|
|
|
auto tool = PerfProfilerTool::instance();
|
|
|
|
|
connect(tool->stopAction(), &QAction::triggered, runControl(), &RunControl::initiateStop);
|
|
|
|
|
connect(runControl(), &RunControl::started, PerfProfilerTool::instance(),
|
|
|
|
|
&PerfProfilerTool::onRunControlStarted);
|
|
|
|
|
connect(runControl(), &RunControl::stopped, PerfProfilerTool::instance(),
|
|
|
|
|
&PerfProfilerTool::onRunControlFinished);
|
|
|
|
|
connect(runControl(), &RunControl::finished, PerfProfilerTool::instance(),
|
|
|
|
|
&PerfProfilerTool::onRunControlFinished);
|
|
|
|
|
|
|
|
|
|
PerfDataReader *reader = m_perfParserWorker->reader();
|
|
|
|
|
if (auto prw = qobject_cast<LocalPerfRecordWorker *>(m_perfRecordWorker)) {
|
|
|
|
|
// That's the local case.
|
|
|
|
|
DeviceProcess *recorder = prw->recorder();
|
|
|
|
|
connect(recorder, &DeviceProcess::readyReadStandardError, this, [this, recorder] {
|
|
|
|
|
appendMessage(QString::fromLocal8Bit(recorder->readAllStandardError()),
|
|
|
|
|
Utils::StdErrFormat);
|
|
|
|
|
});
|
2019-01-07 14:30:39 +01:00
|
|
|
connect(recorder, &DeviceProcess::readyReadStandardOutput, this, [this, reader, recorder] {
|
|
|
|
|
if (!reader->feedParser(recorder->readAllStandardOutput()))
|
2019-03-01 16:58:35 +01:00
|
|
|
reportFailure(tr("Failed to transfer Perf data to perfparser."));
|
2018-10-18 11:57:19 +02:00
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
reportStarted();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
} // namespace Internal
|
|
|
|
|
} // namespace PerfProfiler
|
|
|
|
|
|
|
|
|
|
#include "perfprofilerruncontrol.moc"
|