Proposing elfutils-0.187 for Monday 25 April
Hi, It has been 5 months since elfutils 0.186 was released. There have been more than 70 commits since then. And 20 bugs closed. I propose we do an elfutils 0.187 release Monday 25 April. There are still a couple of unreviewed patches: https://patchwork.sourceware.org/project/elfutils/list/ I'll try to go over them all before the release. If there are any other issues left, please let me know. Lets try to do the next release in 3 months, so there isn't such a big gap between releases. Cheers, Mark
Re: PATCH: testsuite debuginfod
Hi Frank, On Sun, 2021-12-05 at 18:30 +0100, Mark Wielaard wrote: > On Tue, Oct 05, 2021 at 06:55:34PM +0200, Mark Wielaard wrote: > > On Thu, 2021-09-30 at 10:50 -0400, Frank Ch. Eigler via Elfutils-devel > > wrote: > > > commit 85602ff68179053f19a2005df4fc653a69757584 (HEAD -> master) > > > Author: Frank Ch. Eigler > > > Date: Thu Sep 30 10:48:00 2021 -0400 > > > > > > debuginfod testsuite: Use ! CMD syntax. > > > > > > Previously, we had a mishmash of iffy && || constructs to > > > reverse the rc of a subprocess that we expected to fail. > > > Now use > > >! CMD > > > or > > >! (CMD | CMD) > > > more systematically where possible. > > > > > > Signed-off-by: Frank Ch. Eigler > > > > Thanks, the && || conditionals do make my head hurt (I am not as > > logical as I like). This looks much simpler. > > > > I wish we can use this. But we use -e to make any failing command > > (pipeline) fail the script/test. And man bash says (under -e Exit > > immediately): > > > >The shell does not exit if the command that fails is part of the > >command list immediately following a while or until keyword, part > >of the test following the if or elif reserved words, part of any > >command executed in a && or || list except the command following > >the final && or ||, any command in a pipeline but the last, or if > >the command's return value is being inverted with !. > > > > So I am afraid any '! should_fail_but_does_not' will not actually exit > > and so doesn't FAIL the test. Could you double check that? > > Have you looked into this? Is it something we can workaround? Or > should we drop this idea for now? I think we should drop this patch for now. Or are you still working on it? Thanks, Mark
Re: [PATCH v2] config: simplify profile.*sh.in
Hi, On Wed, 2022-01-19 at 13:31 +0100, наб via Elfutils-devel wrote: > On Tue, Jan 18, 2022 at 11:13:28AM -0500, Frank Ch. Eigler wrote: > > You mean "prefix=@prefix@". And it's not needless, > > because @sysconfdir@ often expands to "$prefix/something", > > which requires a prefix var to be set for evaluation. > > I did, and yeah, that's right. Guess it was so outlandish that I > completely missed it. Dropped. > > > > 2. Simplify needless sh -c "cat glob 2>/dev/null" > > >into cat glob 2>/dev/null > > > > This is not needless, but I forget the exact details. It probably > > has > > to do with the $prefix expansion just above, or perhaps glob > > non-matching error handling. > > Well, no, as-written, it is needless. It's also incorrect, > since it's subject to word-splitting (=> a broken glob) again. > > But, yeah, turns out csh does have "glob non-matching error handing", > which is both news to me and a blast from a V3-era past. > That being said, it was also broken, because under csh > false | cat > fails, for some inexplicable reason, and if the glob "fails", > so does cat, so so does sh. > > I've restored it, in a fashion that isn't subject to re-splitting, > and actually protects -e mode, for csh. > > v2 scissor-patch below. > > Please keep me in CC, as I'm not subscribed, > наб > > -- >8 -- > 1. Simplify needless sh -c "cat glob 2>/dev/null" >into cat glob 2>/dev/null under sh >and fix re-expansion/-e protection under csh > 2. Use $( instead of ` under sh > 3. Assign to D_U directly and either export it or unset it This seems reasonable to me, but I did have to lookup the exact workings of sh -c to make sense of it. -c string If the -c option is present, then commands are read from string. If there are arguments after the string, they are assigned to the positional parameters, starting with $0. I have added a ChangeLog entry: 2022-01-19 Ahelenia Ziemiańska * profile.csh.in: Set DEBUGINFOD_URLS directly. Use "$0" and : in sh -c. * profile.sh.in: Set DEBUGINFOD_URLS directly. Don't use sh -c. Use $() instead of ``. Full commit at: https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=simplify-profile Frank, do you have any more concerns with this patch? Ahelenia, under which shells have you tested this? Thanks, Mark
Re: Proposing elfutils-0.187 for Monday 25 April
Hey Mark, The latest patch for PR28928 locates in bugzilla, and it's attached in https://sourceware.org/bugzilla/show_bug.cgi?id=28928 Di On Fri, Apr 15, 2022 at 6:41 PM Mark Wielaard wrote: > Hi, > > It has been 5 months since elfutils 0.186 was released. There have been > more than 70 commits since then. And 20 bugs closed. > > I propose we do an elfutils 0.187 release Monday 25 April. > > There are still a couple of unreviewed patches: > https://patchwork.sourceware.org/project/elfutils/list/ > I'll try to go over them all before the release. > > If there are any other issues left, please let me know. > > Lets try to do the next release in 3 months, so there isn't such a big > gap between releases. > > Cheers, > > Mark > >
symbol resolution differences with -flto
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 trying to figure out the
breakage. I found at least one situation that is seemingly related to the
user's issue. Below are some observation of mine and then some questions, as I
cannot explain this situation and hope that someone around here has more
knowledge on how to handle this correctly.
First of all, the issue arises in resolving this symbol:
```
$ nm -S /home/milian/projects/compiled/kf5/lib/libKDevPlatformUtil.so.
5.8.220770 | grep addPath
0003d490 0207 T _ZN8KDevelop4Path7addPathERK7QString
```
In perfparser, we employ some tricks to increase symbol resolution
performance. One of those is to put all symbols into a sorted list for faster
lookups. I.e. we iterate over dwfl_module_getsymtab and
dwfl_module_getsym_info. For the above symbol, we actually find two matches
there. First the same that we obtain via `nm` above:
```
0x3d490 0x207 _ZN8KDevelop4Path7addPathERK7QString
```
But then there's a second match for this symbol, but that one has a zero
`addr` and `size` returned by `dwfl_module_getsym_info`...
```
0x0 0x0 _ZN8KDevelop4Path7addPathERK7QString
```
I'm unsure if this is related, but it's odd for sure.
To make this situation even more odd: The address we fail to resolve is at
offset `0x68590` which is _very_ far away from the symbol address reported
above. Yet `eu-addr2line` has no problem in resolving it, and it also claims
it's not inlined?
```
eu-addr2line -f -i -C -e /home/milian/projects/compiled/kf5/lib/
libKDevPlatformUtil.so.5.8.220770 -a 68590
0x00068590
KDevelop::Path::addPath(QString const&)
/home/milian/projects/kde/src/kdevelop/kdevplatform/util/path.cpp:408:14
```
How can this code location map to a symbol that is outside the range specified
in the symtab?
Furthermore, when I look at the dissassembly at the offset `0x68590`, then the
code is seemingly in a totally different part... I.e.:
```
00068283 <_ZL9splitPathRK7QString>:
...
683bd: c3 ret
void Path::addPath(const QString& path)
{
683be: 55
6858c: e8 fb f9 ff ff call 67f8c
<_ZL9cleanPathP7QVectorI7QStringEb>
}
68591: bb 01 00 00 00 mov$0x1,%ebx
68596: 48 8d 85 50 ff ff fflea-0xb0(%rbp),%rax
6859d: 48 89 c7mov%rax,%rdi
```
>From my understanding of the disassembly output, the function
<_ZL9splitPathRK7QString> 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
Re: [PATCH v2] config: simplify profile.*sh.in
Hi! On Fri, Apr 15, 2022 at 01:48:23PM +0200, Mark Wielaard wrote: > I have added a ChangeLog entry: > > 2022-01-19 Ahelenia Ziemiańska > >* profile.csh.in: Set DEBUGINFOD_URLS directly. Use "$0" and : >in sh -c. >* profile.sh.in: Set DEBUGINFOD_URLS directly. Don't use sh -c. >Use $() instead of ``. > > Full commit at: > https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=simplify-profile Yeah, that looks about right. > Ahelenia, under which shells have you tested this? csh, dash, and bash, whichever versions were current in sid x32 when I posted this (not that it matters much, I think, the sh version is specified by POSIX, and csh is unchanging). Best, наб signature.asc Description: PGP signature
Re: parallel downloads of multiple debuginfo files
Hi, On Fri, 2022-04-08 at 17:31 -0400, Frank Ch. Eigler via Elfutils-devel wrote: > Hi - > > > But once again - isn't this a problem that everyone using dwfl 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? > > I suspect not many apps are going to have a complete list of files > they know they'll need a priori. A live profiler tends to find out > about target files gradually. A debugger uses debuginfo to help > enumerate other debuginfo. DWZ files can only be even known of when > the base DWARF file is fetched. A "two stage" profiler like perf, which first just records build-ids, addresses and stack dumps, then afterwards does address/symbol/dwarf resolution and backtracing, can know before the second stage all the needed debuginfo for all the build-ids recorded. And a debugger can be "greedy" and try to make sure all debuginfo for a core file or live process is available up front. I believe gdb for example does try to generate symbol tables for everything on startup in a background thread so everything is available quickly once the user is really starting to debug. > So yeah I'm not sure there exists a > widespread general problem for which multithreading is not a workable > solution. That said, I am not sure multithreading is a real solution for the above scenarios. Doing parallel downloads is often not that efficient. It is better to reuse the same debuginfo_client handle to download things serially, that way you can reuse the existing connection instead of having to set it up for each download separately. Cheers, Mark
[Bug tools/28928] Wrong dynamic section entry number
https://sourceware.org/bugzilla/show_bug.cgi?id=28928 Mark Wielaard changed: What|Removed |Added Attachment #14042|0 |1 is obsolete|| CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- Created attachment 14064 --> https://sourceware.org/bugzilla/attachment.cgi?id=14064&action=edit readelf: Don't consider padding DT_NULL as dynamic section Good find. And binutils readelf does get this right. I see you made this block PR28873. And you are right that we should first get this correct before doing the the -D dance going through the dynamic segment showing information. But for -d we don't have to go through the phdrs and the dynamic segment, we can just use the section data directly. I made that adjustment and added some ChangeLog entries. See attached and at: https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=pr14042 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/28928] Wrong dynamic section entry number
https://sourceware.org/bugzilla/show_bug.cgi?id=28928 --- Comment #3 from Di Chen --- Thanks Mark, attachment 14064 looks good to me. You are right, we should let patch for "-d --use-dynamic" (part of Bug 28873) take care of using phdr(PT_DYNAMIC) to get the section data. Because I was considering "-d --use-dynamic", so I mixed this fix with dynamic phdr -> section data, I agree with using section data directly for this fix. -- You are receiving this mail because: You are on the CC list for the bug.
