scache.cpp;h=8ff26d09a71aff0343378ff062c8fb2fcf601c08;hb=refs/heads/
master
[5]: https://codereview.qt-project.org/gitweb?p=qt-creator/
perfparser.git;a=blob;f=app/
perfdwarfdiecache.cpp;h=10e432e64cdce6c5e9e6a72a49a1cd73ddb9e7ce;hb=refs/
heads/master
Good luck!
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
.
> > Also there is a mingw container setup on builder.sourceware.org which
> > we might use for doing CI on the port?
> > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile->
> > > fedora-mingw
>
> I'll have to look at it in detail, but that also sounds great! So far
> there is no automated CI. I just run the tests manually when I change
> anything.
>
> best regards,
> Ulf
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
but is the CFI/FDE data also tied to such process-specific data? Or could it
in theory be reuses across `dwfl*` instances?
Thanks
[1]: https://github.com/KDAB/hotspot/issues/394
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
ide accordingly (i.e.
enable multi-threading or not)?
Cheers
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Donnerstag, 18. Juli 2024 17:56:39 MESZ Aaron Merey wrote:
> Hi Milian,
>
> On Thu, Jul 18, 2024 at 6:14 AM Milian Wolff wrote:
> > On Donnerstag, 18. Juli 2024 00:33:59 MESZ Aaron Merey wrote:
> > > v1 can be found at
> > > https://sourceware.org/pipermail/
sym names for @plt entries like in
the case above?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Wednesday, January 4, 2017 2:42:23 PM CET Mark Wielaard wrote:
> On Wed, Jan 04, 2017 at 01:41:26AM +0100, Milian Wolff wrote:
> > how do I get symbol information for @plt entries?
>
> Short answer. You cannot with the dwfl_module_getsym/addr*
> functions. And we don't h
rrent dwfl_linux_kernel_report_kernel API - how is this intended to
be handled? Should one instead use dwfl_linux_kernel_report_offline when one
wants to support cross-machine analysis?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
ions for a fitting name though, in C++ I'd simply use an overload but
here with plain C... ;-)
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
On Mittwoch, 29. März 2017 21:48:08 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Wed, 2017-03-29 at 16:50 +0200, Milian Wolff wrote:
> > would you be willing to accept a patch that adds an alternative to
> > dwfl_attach_state taking an Ebl pointer instead of
On Thursday, March 30, 2017 12:57:33 PM CEST Mark Wielaard wrote:
> On Wed, 2017-03-29 at 23:57 +0200, Milian Wolff wrote:
> > On Mittwoch, 29. März 2017 21:48:08 CEST Mark Wielaard wrote:
> > > Would it help your use case if there was a dwfl_init_state (Dwfl *dwfl,
> > &
ctions::glTexImage2D qopenglfunctions.h:1022
...
So, please consider reviewing and merging this.
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
On Monday, April 3, 2017 11:23:25 PM CEST Jan Kratochvil wrote:
> On Mon, 03 Apr 2017 11:00:03 +0200, Milian Wolff wrote:
> > I just got a report from a colleague. As-is, elfutils would fail to unwind
> > from the following location in his application:
> >
> > 0x113
On Wednesday, April 5, 2017 2:46:34 PM CEST Mark Wielaard wrote:
> On Thu, 2017-03-30 at 13:14 +0200, Milian Wolff wrote:
> > > OK. How do you know the Elf architecture in that case? How and by what
> > > is it given? Is that an EM constant or some architecture string?
&g
non-eu addr2line does? If so, can
that be added upstream too, such that dwfl_module_addrdie can be relied on?
I've seen it on clang 3.6, 4 and 5. Neither passing -g3 nor -gdwarf-aranges
helps.
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
On Freitag, 5. Mai 2017 15:06:48 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Thu, 2017-05-04 at 18:05 +0200, Milian Wolff wrote:
> > I noticed that elfutils fails to handle clang binaries when we want to
> > find a DIE for a certain address. I.e. dwfl_module_addrdie return
#x27;ll notice a lot of lines of
the form
unwind: access_mem 0xffd7 not inside range
0x7ffca0a86aa8-0x7ffca0a88aa8
which is also what we see in our perfparser utility.
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
are doing with my DSOs?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Donnerstag, 1. Juni 2017 22:57:12 CEST Milian Wolff wrote:
> Hey all,
>
> on my ArchLinux box I regularly see cases where libdw fails to unwind
> properly. I can reproduce this both with upstream perf as well as with the
> perfparser utility.
>
> How should I debug this,
On Donnerstag, 1. Juni 2017 22:57:12 CEST Milian Wolff wrote:
> Hey all,
> heaptrack_gui 2228 135073.400474: 613969 cycles:
> 108c8e [unknown] (/usr/lib/libQt5Core.so.5.8.0)
> @@ -533,8 +529,6 @@
> 2170af [unknown] (/usr/lib/libQ
On Freitag, 2. Juni 2017 15:26:10 CEST Milian Wolff wrote:
> On Donnerstag, 1. Juni 2017 22:57:12 CEST Milian Wolff wrote:
> > Hey all,
>
>
>
> > heaptrack_gui 2228 135073.400474: 613969 cycles:
> > 108c8e [unknown] (/usr/lib/libQt5Cor
On Dienstag, 13. Juni 2017 16:20:25 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Thu, 2017-06-01 at 22:57 +0200, Milian Wolff wrote:
> > How should I debug this, or how can I report a good bug report for this? I
> > guess I could upload a perf archive and document the steps
On Dienstag, 13. Juni 2017 16:06:01 CEST Mark Wielaard wrote:
> On Thu, 2017-06-01 at 22:46 +0200, Milian Wolff wrote:
> > in the perfparser that Ulf wrote, and to which I'm contributing too, we
> > often see abnormal data being passed to the memory_read callback we
> >
On Friday, January 6, 2017 8:17:53 PM CEST Mark Wielaard wrote:
> On Fri, Jan 06, 2017 at 11:28:25AM +0100, Milian Wolff wrote:
> > On Wednesday, January 4, 2017 2:42:23 PM CET Mark Wielaard wrote:
> > > Longer answer. An address pointing into the PLT does
> > > re
On Freitag, 7. Juli 2017 13:03:32 CEST Mark Wielaard wrote:
> Hi Milian,
>
> First congrats on https://www.kdab.com/hotspot-gui-linux-perf-profiler/
> Very cool.
>
> On Wed, 2017-07-05 at 15:34 +0200, Milian Wolff wrote:
> > On Friday, January 6, 2017 8:17:53 PM CEST Ma
On Monday, July 10, 2017 1:06:27 PM CEST Milian Wolff wrote:
> On Freitag, 7. Juli 2017 13:03:32 CEST Mark Wielaard wrote:
> > Hi Milian,
> >
> > First congrats on https://www.kdab.com/hotspot-gui-linux-perf-profiler/
> > Very cool.
> >
> > On Wed, 2017-0
for some
issues we are seeing, such as supposedly overlapping modules.
Looking at the Dwfl API, I cannot figure out how to feed the mapping directly.
There's dwfl_report_module, but how would I associate an Elf* and int fd with
it, as done by dwfl_report_elf?
Thanks
--
Milian Wo
On Dienstag, 20. März 2018 23:05:49 CET Mark Wielaard wrote:
> Hi Milian,
Hey Mark :)
> On Sat, Mar 17, 2018 at 02:14:48PM +0100, Milian Wolff wrote:
> > a recurring issue in the libdwfl integration of perf and perfparser are
> > supposedly overlapping modules. The perf data
On Mittwoch, 21. März 2018 14:01:41 CET Milian Wolff wrote:
> On Dienstag, 20. März 2018 23:05:49 CET Mark Wielaard wrote:
> > Hi Milian,
>
> Hey Mark :)
>
> > On Sat, Mar 17, 2018 at 02:14:48PM +0100, Milian Wolff wrote:
> > > a recurring issue in the libdwfl i
On Mittwoch, 21. März 2018 22:21:13 CET Mark Wielaard wrote:
> Hi Milian,
>
> On Wed, Mar 21, 2018 at 02:01:41PM +0100, Milian Wolff wrote:
> > Here's the code for the perf tools:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/tools
On Mittwoch, 21. März 2018 22:31:07 CET Mark Wielaard wrote:
> On Wed, Mar 21, 2018 at 03:23:51PM +0100, Milian Wolff wrote:
> > Here's one way to investigate where perf and dwfl disagree on the file
> > mappings:
> >
> > diff --git a/tools/perf/util/unwind-libd
g.
>
> I realize we could optimize the reporting a bit, with the dwfl_report_end
> callback Mark mentioned, but if you have addresses into two overlapping
> ELFs in one sample, that's fundamentally impossible to unwind.
In the concrete data file I have at hand, no chunks got lost, so I
ces absolute paths everywhere.
HTH
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
do:
~
git clone --branch=perf/core git://git.kernel.org/pub/scm/linux/kernel/git/
acme/linux.git
cd linux/tools/perf
make NO_LIBUNWIND=1
~
The perf binary in the last folder can than be used as a drop-in replacement.
Since I consider this issue a serious blocker, I would like to see it f
On Mittwoch, 26. September 2018 16:38:43 CEST Milian Wolff wrote:
> On Friday, September 21, 2018 3:07:29 PM CEST Mark Wielaard wrote:
> > On Wed, 2018-09-19 at 14:24 +0200, Ulf Hermann wrote:
> > > > We suspect perf to offset its recording-addresses of mmapped
> > &g
explicitly say how much of a file to map.
But to make this discussion easier to follow for others, I'll create some
standalone cpp code that takes a `perf script --show-mmap-events | grep
PERF_RECORD_MMAP` input file and then runs this through elfutils API to
reproduce the issues we are fa
On Donnerstag, 11. Oktober 2018 20:14:43 CEST Milian Wolff wrote:
> On Donnerstag, 11. Oktober 2018 19:37:07 CEST Mark Wielaard wrote:
> > Hi,
> >
> > My apologies for not having looked deeper at this.
> > It is a bit tricky and I just didnt have enough time to
>
On Donnerstag, 11. Oktober 2018 20:14:43 CEST Milian Wolff wrote:
> On Donnerstag, 11. Oktober 2018 19:37:07 CEST Mark Wielaard wrote:
> > Hi,
> >
> > My apologies for not having looked deeper at this.
> > It is a bit tricky and I just didnt have enough time to
>
On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Mon, 2018-10-15 at 22:38 +0200, Milian Wolff wrote:
> > here's one example of mmap events recorded by perf:
> >
> > 0x7fac5ec0b000 to 0x7fac5ed9a000, len = 0x18f000, offset
> &
On Montag, 15. Oktober 2018 23:06:07 CEST Milian Wolff wrote:
> On Montag, 15. Oktober 2018 23:04:52 CEST Mark Wielaard wrote:
> > Hi Milian,
> >
> > On Mon, 2018-10-15 at 22:38 +0200, Milian Wolff wrote:
> > > here's one example of mmap events recorded by p
On Montag, 15. Oktober 2018 22:38:53 CEST Milian Wolff wrote:
> On Donnerstag, 11. Oktober 2018 20:14:43 CEST Milian Wolff wrote:
> > On Donnerstag, 11. Oktober 2018 19:37:07 CEST Mark Wielaard wrote:
> > > Hi,
> > >
> > > My apologies for not having look
rks once more in such situations.
Signed-off-by: Milian Wolff
---
libdw/dwarf_getcfi_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libdw/dwarf_getcfi_elf.c b/libdw/dwarf_getcfi_elf.c
index 315cc02f..4bcfe5cd 100644
--- a/libdw/dwarf_getcfi_elf.c
+++ b/libdw/dwarf
According to the DWARF v3 standard §6.4.3 3., all call frame
instructions up to L1 <= L2 should be interpreted for an FDE.
Elfutils currently only interprets L1 < L2, potentially missing
some instructions when L1 directly points at a DW_CFA_*_loc boundary.
This patch changes the behavior and makes
Please ignore this patch for now - I only looked at one specific case where
this changed the behavior to be in line with libunwind. Sadly, it breaks other
previously working situations. I need to look at this in more detail.
Cheers
On Donnerstag, 1. November 2018 09:48:18 CET Milian Wolff
On Donnerstag, 1. November 2018 10:12:41 CET Milian Wolff wrote:
> Please ignore this patch for now - I only looked at one specific case where
> this changed the behavior to be in line with libunwind. Sadly, it breaks
> other previously working situations. I need to look at this in mo
On Montag, 5. November 2018 00:04:32 CET Mark Wielaard wrote:
> On Mon, 2018-10-29 at 16:21 +0100, Milian Wolff wrote:
> > On my system with g++ (GCC) 8.2.1 20180831 with GNU gold (GNU
> > Binutils
> > 2.31.1) 1.16, the .eh_frame section does not have type PROGBITS
>
On Dienstag, 6. November 2018 12:06:57 CET Mark Wielaard wrote:
> Hi Milian,
>
> On Tue, 2018-11-06 at 00:12 +0100, Milian Wolff wrote:
> > On Montag, 5. November 2018 00:04:32 CET Mark Wielaard wrote:
> >
> > Interestingly, when I try to reproduce this on my la
e scopes than dwarf_getscopes.
For me, the documentation for `dwarf_getscopes` is confusing. I would have
expected that it should be a superset of dwarf_getscopes_die, but apparently
that is not the case.
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
rent IPs, but I don't see any way to
leverage this to speed up the processing task.
Thanks, any input would be welcome
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Montag, 15. Juni 2020 18:54:41 CEST Josh Stone wrote:
> On 6/13/20 10:40 AM, Milian Wolff wrote:
> > Has anyone an idea on how to to post-process the DWARF data to optimize
> > the
> > lookup of inlined frames?
>
> SystemTap implements its own cache for repea
dress `0x5a40` should come from the second mapping,
which has an offset 0x0 and starts at `0x5000` and has a size of
`0x1000`. How can that possibly map to the `main` symbol which has an offset
of `0x1a40`?
Does anyone know what's going on here?
Thanks
--
Milian
On Montag, 11. Januar 2021 17:05:30 CET Mark Wielaard wrote:
> Hi Milian,
>
> On Wed, 2020-12-30 at 16:51 +0100, Milian Wolff wrote:
> > I stumbled upon a strange behavior while symbolizing a perf.data file
> > with
> > hotspot/perfparser/elfutils that I have trouble
debuginfod
experience, I do not necessarily want to raise the minimum elfutils version
requirement just for that purpose.
Many thanks again!
--
Milian Wolff
http://milianw.de
g dwfl which uses debuginfod
internally. I guess that happens via the `dwfl_*find_*` standard callbacks
provided in `libdwfl.h`. That works perfectly fine. I simply want a bit more
control over the debuginfod usage that happens internally in dwfl.
Is maybe a `debuginfod_client *dwfl_debuginfod(void
tion.
Would you be OK with me simply copying over the contents from the man page
over to doxygen? Or is there a better process in place to prevent such kind of
documentation duplication? I would have expected that the man pages for API
documentation are generated from e.g. doxygen which does not seem to be the
case here?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
me would become much faster again.
Was there a deliberate decision against caching negative server side lookups?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
```
dwfl_standard_find_debuginfo > debuginfod_query_server > curl_multi_wait
```
This accounts for ~2.5s of off-CPU time in my case. If you are saying that
negative lookups are cached, then what is this? Why would a second run of the
same dwfl-using application with the same input data
something like HTTP/3's ability to download mutiple assets over a single
connection (maybe even in parallel)?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
is going to
encounter? Should we not try to find a general solution to this problem and
fix it for all consumers of the API?
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Freitag, 8. April 2022 22:59:55 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Fri, Apr 08, 2022 at 10:45:10PM +0200, Milian Wolff wrote:
> > In the off-CPU flame graphs I clearly see this callchain when
> > DEBUGINFOD_URLS is set:
> >
> > ```
On Freitag, 8. April 2022 23:34:06 CEST Aaron Merey wrote:
> Hi Milian,
>
> On Fri, Apr 8, 2022 at 5:08 PM Milian Wolff wrote:
> > I can reproduce it now suddenly with debuginfod-find too:
> >
> > ```
> > $
> > debuginfod-find debuginfo 8
On Freitag, 8. April 2022 23:56:15 CEST Milian Wolff wrote:
> Which in turn points at the code that does cache cleanup in
> `debuginfod_query_server`. I now used `rr` to record such a bogus run and I
> clearly see that `(time(NULL) - st.st_mtime <= cache_miss)` is false and it
>
permission files so that they
> are unlinked immediately if found.
Ah, since this fixes my issue, I don't need to provide another patch for that
purpose I guess. Mark, will you merge this then please? I tested it too, so
feel free to include the following, if you want:
Tested-by: Milian Wo
On Freitag, 8. April 2022 21:50:18 CEST Milian Wolff wrote:
> On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote:
> > > Will the default code that uses debuginfod from within dwfl then pick up
> > > my
> > > new client object and use that? I f
starts at 00068283. But what does this `void
Path::addPath` line mean - is that inlined? Why then does addr2line only show
addPath and not the splitPath function it gets inlined in?
It would be great if someone could educate me on how this is handled and how
`0x68590` is mapped to `addPath` directly.
Thanks
--
Milian Wolff
http://milianw.de
On Freitag, 15. April 2022 14:09:02 CEST Milian Wolff wrote:
> Hey there,
>
> a user reported broken symbol resolution in hotspot/perfparser which uses
> elfutils when he's using it on code compiled with LTO.
>
> I think I can reproduce this, and now spent some time try
On Samstag, 9. April 2022 15:44:34 CEST Milian Wolff wrote:
> On Freitag, 8. April 2022 21:50:18 CEST Milian Wolff wrote:
> > On Freitag, 8. April 2022 21:44:32 CEST Frank Ch. Eigler wrote:
> > > > Will the default code that uses debuginfod from within dwfl then pick
oing. Right now, it feels like the
tool is frozen as no feedback is given to the user.
b) Allow to disable debuginfod. But that is already doable by unsetting the
DEBUGINFOD_URLS env var, and as such I don't necessarily need any additional
API for that?
As such, only a) is something that needs immediate attention imo, and what my
API proposal is covering.
Thanks
--
Milian Wolff
http://milianw.de
tput. I want to show the download progress and
status graphically instead.
[1]: https://github.com/KDAB/hotspot/
[2]: https://github.com/KDAB/gammaray
--
Milian Wolff
http://milianw.de
return NULL when debuginfod integration was
disabled.
Signed-off-by: Milian Wolff
---
libdw/libdw.map | 5 +
libdwfl/ChangeLog | 5 +
libdwfl/Makefile.am | 5 +
libdwfl/debuginfod-client.c | 23 ++-
libdwfl/libdwfl.h | 10
On Donnerstag, 7. Juli 2022 18:40:05 CEST Aaron Merey wrote:
> Hi Milian,
>
> On Thu, Jul 7, 2022 at 10:47 AM Milian Wolff wrote:
> > Dwfl can use debuginfod internally, which was so far totally opaque
> > to the outside. While the functionality is great for users of the
&
return NULL when debuginfod integration was
disabled.
Signed-off-by: Milian Wolff
---
libdw/libdw.map | 5 +
libdwfl/ChangeLog | 5 +
libdwfl/Makefile.am | 5 +
libdwfl/debuginfod-client.c | 23 ++-
libdwfl/libdwfl.h | 10
5720: st_value out of bounds
section [29] '.symtab': symbol 27227: st_value out of bounds
```
Does anyone know how this can happen? Is this a bug in the toolchain?
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
ll the
issues are all unrelated to my patch? Or did I break something? See e.g.:
[1]: https://builder.sourceware.org/buildbot/#/builders/39/builds/41
Thanks
--
Milian Wolff
m...@milianw.de
http://milianw.de
signature.asc
Description: This is a digitally signed message part.
On Mittwoch, 13. Juli 2022 22:38:51 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Wed, Jul 13, 2022 at 09:36:45PM +0200, Milian Wolff wrote:
> > On Mittwoch, 13. Juli 2022 20:20:04 CEST Aaron Merey wrote:
> > > There weren't any concerns with the patch so I've
On Dienstag, 26. Juli 2022 17:28:11 CEST Mark Wielaard wrote:
> Hi Milian,
>
> On Mon, 2022-07-11 at 18:40 +0200, Milian Wolff wrote:
> > in heaptrack I have code to runtime attach to a program and then
> > rewrite the
> > various rel / rela / jmprel tables to intercep
On Mittwoch, 11. Dezember 2024 17:09:19 Mitteleuropäische Normalzeit Christian
Hergert wrote:
> On vacation until 2025 so my replies will be sparse here :)
>
> On 12/11/24 3:24 AM, Milian Wolff wrote:
> > For symmetry reasons, we also need an `..._end` method. And what about
modules all the time to elfutils
- esp. in large applications with compressed debug information it can often be
that you only need a fraction of the loaded shared symbols e.g. Also consider
debuginfod - you don't want to download everything (such as GDB would be
doing), you only want t
tionality I'm actually adding. We
> could also have Dwfls share data through a hidden global variable, but it
> seems gross to enable such sneaky caching without the user of the library
> explicitly requesting it via Dwfl_Process_Table.
I agree with your proposal. But please take thr
79 matches
Mail list logo
