| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Apparently "i686" can show up in perf.data files. Let's just accept all
kinds of things that look remotely like a valid architecture, just to be
safe.
Change-Id: Ieb2af7c2809ba7799002f94f3aff0949b141194c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
|
|
| |
The data structure used to be shorter and we should not fail on that.
Change-Id: Id2c46a3399d680462a28fc3609622042d1f526bf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
|
|
|
|
| |
This way we don't need a complicated synchronization setup when the data
is tunneled through an SSH connection, which might take a while to
start.
Change-Id: Ib42aede7e751258e928224326ee46fe9252be8b3
Reviewed-by: hjk <hjk@qt.io>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
app/main.cpp
Change-Id: Ic3cd7ca4b5434b01187a2daa060818de0b31f3d5
|
| |
| |
| |
| |
| | |
Change-Id: Iceb0fe3e2321778038570fb3ab9310d566d3527e
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Ieef754ad2eec933ba416ded81de3bdcdeaae5588
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I2b9b4b02381d500ba853528a25b37dbecd8fd902
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Ib4fcaaf3408d89abeb9230aafbdb041f3891c7e2
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This prettifies the debug output of warnings like this one:
Before:
warning: perfparser/unknown: feature not properly read 13 244 212
After:
warning: perfparser/unknown: feature not properly read PerfHeader::Feature(CPU_TOPOLOGY) 244 212
Change-Id: I8cf0921eabd0fb8971246de58fd4f2e2c0f6b472
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Whenever we query for dwfl_addrmodule, we have to ensure the returned
module matches the mapping we expect. To do so, a new method is
introduced that wraps dwfl_addrmodule. If no module is found, or the
mapping mismatches, we report the expected elf map.
This does not fix any obvious issue but seems like the correct thing
to do. Additionally, it allows a follow-up fix.
Change-Id: I03208aaf6a64477ff7a8bdd5eb893ca34fd3038b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows us to parse perf.data files from other machines that
we distributed via `perf archive`. Additionally, we can now parse
older perf.data files from the same machine when the kernel got
updated in the meantime.
The kallsyms build-id cache is ignored when kallsyms is set
explicitly on the command line. Sometimes the kallsyms file in
the build-id cache is broken. Or maybe we just want to enforce
reading a different kallsyms file. This also mimicks the
behavior of `perf report --kallsyms` in such a case.
Change-Id: Iddec9ceb4e2e706305297c957ab85d29c247c9bb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By remembering the path under which a file was originally referenced
in the mmap call, we can use this information to find debug link
files. I.e. we will now try to find the debug link file in the
original binary target folder, which is where this debug link file
often resides.
This is useful for lazy people like me who don't want to set the
application path every time they use perfparser.
Change-Id: I8e33f137b186ed857b9b4da1d0618d0ae903d0cd
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The call to dwfl_frame_pc potentially advances the internal
unwinder state when we query for the isactivation flag. This can
then lead to breakage when the about-to-be-returned PC lies in
a not-yet-reported module.
To fix this, we now ask first for the PC, which is cheap as it
just forwards a data member of the Dwfl_Frame state. Then we
ensure the module that contains this PC is properly reported to
dwfl. Only then do we ask for the isactivation flag by calling
dwfl_frame_pc a second time.
This fixes many broken backtraces. In perf upstream I have
submitted a similar fix. There, we can more easily compare the
libdw unwinder with libunwind. Here is the corresponding
output of the two:
Working libunwind and libdw with this patch applied:
~~~~~
heaptrack_gui 2228 135073.400474: 613969 cycles:
108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0)
109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0)
147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0)
109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0)
10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0)
211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0)
92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0)
2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0)
297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0)
78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui)
20439 __libc_start_main (/usr/lib/libc-2.25.so)
78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)
heaptrack_gui 2228 135073.401156: 569521 cycles:
131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0)
1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0)
21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0)
2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0)
279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0)
e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0)
f5a1c QGuiApplicationPrivate::createPlatformIntegration (/usr/lib/libQt5Gui.so.5.8.0)
f650c QGuiApplicationPrivate::createEventDispatcher (/usr/lib/libQt5Gui.so.5.8.0)
298524 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
1589e8 QApplicationPrivate::init (/usr/lib/libQt5Widgets.so.5.8.0)
78622 main (/home/milian/projects/compiled/other/bin/heaptrack_gui)
20439 __libc_start_main (/usr/lib/libc-2.25.so)
78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)
~~~~~
Broken libdw, i.e. status quo without this patch. Note how the first sample
is randomly missing two frames close to the end. The second stack breaks
completely.
~~~~~
heaptrack_gui 2228 135073.400474: 613969 cycles:
108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1093bc [unknown] (/usr/lib/libQt5Core.so.5.8.0)
109e7b QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
1470ff [unknown] (/usr/lib/libQt5Core.so.5.8.0)
147f67 QSystemLocale::query (/usr/lib/libQt5Core.so.5.8.0)
109fbf QLocalePrivate::updateSystemPrivate (/usr/lib/libQt5Core.so.5.8.0)
10aa27 QLocale::QLocale (/usr/lib/libQt5Core.so.5.8.0)
1e02c3 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
2113bb [unknown] (/usr/lib/libQt5Core.so.5.8.0)
211505 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1b5df0 QFileInfo::exists (/usr/lib/libQt5Core.so.5.8.0)
92eb2 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
93423 [unknown] (/usr/lib/libQt5Core.so.5.8.0)
93d2a QLibraryInfo::location (/usr/lib/libQt5Core.so.5.8.0)
2170af [unknown] (/usr/lib/libQt5Core.so.5.8.0)
297c53 QCoreApplicationPrivate::init (/usr/lib/libQt5Core.so.5.8.0)
f7cde QGuiApplicationPrivate::init (/usr/lib/libQt5Gui.so.5.8.0)
20439 __libc_start_main (/usr/lib/libc-2.25.so)
78299 _start (/home/milian/projects/compiled/other/bin/heaptrack_gui)
heaptrack_gui 2228 135073.401156: 569521 cycles:
131633 QString::endsWith (/usr/lib/libQt5Core.so.5.8.0)
1a0701 QDir::cleanPath (/usr/lib/libQt5Core.so.5.8.0)
21b82d [unknown] (/usr/lib/libQt5Core.so.5.8.0)
1b3727 QFileInfo::canonicalFilePath (/usr/lib/libQt5Core.so.5.8.0)
2780c7 QFactoryLoader::update (/usr/lib/libQt5Core.so.5.8.0)
279525 QFactoryLoader::QFactoryLoader (/usr/lib/libQt5Core.so.5.8.0)
e5bd0 QPlatformIntegrationFactory::create (/usr/lib/libQt5Gui.so.5.8.0)
723dbf [unknown] ([unknown])
~~~~~
Both issues are fixed with this patch applied.
Change-Id: Ib2a9394ab2a01a5e65860540a675c277ff15dc8c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These warnings occur quite often and seem to be expected. Spamming
the console with harmless warning output is not good practice, so
demote the harmless issues to debug output.
Change-Id: Iccb402f9e2cb0b1718325d7efa44994223a73d8f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because the byte order was not set on the ID data stream, its values
where parsed in the wrong order, i.e. byte-swapped. This leads to
all kinds of errors later, when we try to lookup the attribute for
a given sample ID - where we parse the value in the correct byte
order.
Change-Id: I06dee77bfe2901daaf1d05c7a5079ae0194adf07
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is mostly done to enable a future patch that will load the
kallsyms file via it's build-id from the debug path.
Change-Id: Ic5c6ecd09dfdf7f8c42b13497f77bc6c43147cf8
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Id90234fbdda5f9a3a3a7e65436b8418228f09f2c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: Iacb08b726c8c43adb2e888de0ef01cf6086f4ad0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|/
|
|
|
|
|
|
|
| |
These sections have an odd name and cannot be found.
We used to show confusing error messages. Instead, we now
ignore these sections and don't try to find a file for them.
Change-Id: Icf5397ad8de84406ad23373b747b4292c8510f8b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|
|
|
|
| |
Change-Id: Ib60487c3c1bc4fdb956a324ce217916dde3d0ccb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|\
| |
| |
| | |
Change-Id: Ia317fd54d0ecb9dc6111dd506b925542f04cb1c9
|
| |
| |
| |
| |
| |
| |
| | |
The result is undefined as dwfl_addrsegment doesn't set mod then.
Change-Id: I3c08519726b8c136e7c24cfc89c34ffc78689619
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When elfutils fails to find a debug link file, try to find it
in all of our search paths like we do for the DSO itself. This
fixes situations where we report the DSO in the ~/.debug path
as identified by its build-id.
Change-Id: If5931b5705e318806bf7d8cc8a63e252ba344a36
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
On windows none of the architecture defines is set.
Change-Id: Iad202a9d1346ee073ca0e2c91da216d25ec6df0a
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: I4d71a668ae6c2a24f568e7ca73170d9fc3fe677e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
We are going to provide elfutils separately.
Change-Id: Ib78b78bf4d11d7921ae5f53a1d1dfa2a1aab3e53
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot handle resources passed to and from elfutils with a different
C library.
Change-Id: I47e789b016d13c249d82a7bd1091cd5fb769ce9d
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Link against elfutils in that directory, and copy files from there in
the deploy step. Also, drop the windows specific library naming dance as
we are never going to build the bundled elfutils on windows.
Change-Id: Ia1dd2583856918b2c2623016f6ed7a80c0c7ef07
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
On windows we want backslashes as directory separators and semicolons as
path separators.
Change-Id: I4feaf4864ddd5c1ddaf7d60a5e8f2de3319af8ef
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If Dwarf_Word is bigger than the target platform's word width, we
otherwise get bogus values this way. The values we read are implicitly
used as pointers and register values and the predefined memory_read
implementations in elfutils do respect the word width.
Change-Id: Idbbb76abc72a9b4bacc075b431fa0c854a54fc2e
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
app/perfsymboltable.cpp
app/perfunwind.cpp
Change-Id: If343bb33fabeb60a3eab566769cf2c4dda88fcc5
|
| |
| |
| |
| |
| |
| |
| |
| | |
Yes, this has to be updated on every release, but I don't see a better
way right now.
Change-Id: Ie81849c75c4e3e55cc0265e66ab01ab60d6d2778
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mmap()'d binaries can overlap in the profiled application's address
space. For example ld.so usually reserves a huge chunk of address space
for itself, which subsequently gets filled with other libraries.
However, libdw won't reliably accept binaries reported "on top of"
existing modules. In seemingly random cases it will complain that the
modules overlap and reject the new one.
So, when we fail to report a module to Dwfl, we mark the symbol cache
as dirty and retry unwinding at most once after clearing the cache.
Clearing the cache resets libdw's state and allows us to report the new
module first, and unwind symbols from it.
Change-Id: Idb5d85afb39e05c0439206b8d4938b79b6173b2c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
So far, perfparser hangs for cases like the following:
echo -n > perf.data.empty
./perfparser --input perf.data.empty
Similarly, we can hang forever when we parse a file that only
contains a perf header but nothing else. This patch adds checks
on the file size for non-sequential inputs (i.e. files) which will
trigger an early return when the input data is broken.
Change-Id: I9c22010dd3628ef65e52a785e36c928445633570
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
The hotst's name mangling will likely differ from the target's anyway.
Change-Id: Iea8672c6697b9526a48dd951973fdbc9c1dae04d
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: I6b4bc432de56d6d068ac0b90ac356bd7783a30c7
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: Ie8073c6f32cd0184ab666ced9d10cf48e59f11c3
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| | |
Change-Id: Id993204f2a0be67edf5d29a9400fb71d63774887
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only newer perf tools will write the debug file to the location
`~/.debug/<buildid>/elf`. Older tools instead will write the debug
file directly to a file called `~/.debug/<buildid>`.
Change-Id: I4d7e24e5774c2d6888cf74a51ec40275647da8f9
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
app/perfelfmap.cpp:111:21: warning: converting to ‘PerfElfMap::ElfInfo’
from initializer list would use explicit constructor
‘PerfElfMap::ElfInfo::ElfInfo(const QFileInfo&, quint64, quint64, quint64, const QByteArray&)’
return {};
Introduced by my recent change to make the ElfInfo constructor
explicit. Sorry, I did not notice it before.
Change-Id: Ib7caedd047f16c98bafc079b92b37543db925cc1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In these cases, we know the expected file size and can thus
compute our current progress value. We do this up to 100 times and
send the progress value as a normalized float percent, i.e. a value
between 0 and 1.
This is a helpful feature, as large data files take a long time
to parse. Showing the user that we make some progress is a good thing.
Change-Id: Icb0c9564e06173a526b726e93d75d4f5b7e8949d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise a statement like qDebug() << QFileInfo() would pick up
this constructor and lead to confusing debug output.
Change-Id: Idb9692bd36983b055409cb347e3175aaf5d75eda
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
When this happens, it is an indicator for a broken file and we
don't even need to go in and parse its contents.
Change-Id: If96e0b1e9fed2cb1069b6d3f4bfc03193321c132
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a wrong kallsym path is given, or the file could not be
parsed correctly, e.g. when it was empty, then we want to
notify the user about this. Otherwise, it may not be clear why
symbol resolution for kernel addresses is broken.
Change-Id: Icf51fa3038810e69a91d332a33495e7678b3977a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By default, both paths pointed to the current working directory.
When I use perfparser in a folder that has many (sub)directories and
files, it is excruciatingly slow:
145338.874552 task-clock (msec) # 0.997 CPUs utilized
13,353 context-switches # 0.092 K/sec
147 cpu-migrations # 0.001 K/sec
4,497 page-faults # 0.031 K/sec
557,953,349,806 cycles # 3.839 GHz
1,009,672,374,742 instructions # 1.81 insn per cycle
238,669,106,565 branches # 1642.156 M/sec
3,017,437,636 branch-misses # 1.26% of all branches
145.823501862 seconds time elapsed
This is on a SSD with an ext4 file system, but going through 104164
files for every mmap event is simply going to take its time.
This patch improves this situation by dropping the implicit recursive
lookup in the current working directory.
The performance impact is tremendous:
4425.928440 task-clock (msec) # 0.999 CPUs utilized
158 context-switches # 0.036 K/sec
1 cpu-migrations # 0.000 K/sec
3,299 page-faults # 0.745 K/sec
17,042,783,950 cycles # 3.851 GHz
36,178,866,218 instructions # 2.12 insn per cycle
8,448,978,802 branches # 1908.973 M/sec
63,738,579 branch-misses # 0.75% of all branches
4.432039578 seconds time elapsed
I.e. this patch makes this case more than 33 times faster.
Change-Id: I9a2c4e84ed739e1fc602be675bd01369b1c39f4c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we fail to find a matching ELF file for an mmap event, the
usefulness of the perfparser can be severly impacted:
- unwinding will not work
- symbol resolution will not work
- potentially other things will not work
As such, report an error to the user when this occurs.
Change-Id: I8a47f8725a29684ac11b24dadb20e669a45d3016
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
app/perfsymboltable.cpp
Change-Id: I66e3a8aa490628246a507769daa32d69ec7b4bd3
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We always get many modules that overlap ld.so. We have to report them
when we find them, or otherwise the unwinding will fail. dwfl apparently
doesn't mind the overlap in this case, so we don't have to clear the
cache before.
Change-Id: I68e9f6fe1653073b555755f546e743621e8c7919
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want to check the parent directory of the file, but that is already
implicit in the entryList() call, which will just return an empty list
if it doesn't exist.
Change-Id: I087ed4fdd6db66e6c02d8604af219c68b5280af7
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
|
| |
| |
| |
| |
| |
| |
| | |
Adaptation to ade8449ea2.
Change-Id: Ic277a584140278905066194feaa4c8188c581c09
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|