elfutils 0.169 released
ELFUTILS 0.169 - http://elfutils.org/
A new release of elfutils is available at:
ftp://sourceware.org/pub/elfutils/0.169/
or https://sourceware.org/elfutils/ftp/0.169/
* NEWS *
backends: Add support for EM_PPC64 GNU_ATTRIBUTES.
Frame pointer unwinding fallback support for i386, x86_64, aarch64.
translations: Update Polish translation.
* GIT SHORTLOG *
Luiz Angelo Daros de Luca (1):
Fix TEMP_FAILURE_RETRY definition when not defined.
Mark Wielaard (20):
Define PACKAGE_URL for older autoconf.
Add -D_FORTIFY_SOURCE=2 to CFLAGS if possible.
backends: Add support for EM_PPC64 GNU_ATTRIBUTES.
libasm: Fix one GCC7 -Wformat-truncation=2 warning.
readelf: Fix off by one sanity check in handle_gnu_hash.
Use the empty string for note names with zero size (without any data).
libelf: Check compression ratio before trying to allocate output buffer.
libelf: Always update last_offset in updatefile and updatemmap.
elflint: Check symbol table data is big enough before checking.
elflint: Don't trust sh_entsize when checking hash sections.
elflint: Sanity check the number of phdrs and shdrs available.
elflint: Don't check section group without flags word.
libdw: Fix dwarf_peel_type infinite loop.
elflint: Support checking ELF files with compressed sections.
Add missing peel_type.c test for commit f339da.
libelf: Initialize n to zero in elf_getarsym.
Revert "Optionally allow unknown symbols in the backtrace tests"
tests: Add core backtracegen check and regen ppc32 backtrace testfiles.
Add i386 frame pointer unwinder.
Prepare for 0.169.
Piotr Drąg (3):
Update Polish translation
Update POTFILES.in
Update Polish translation
Ulf Hermann (26):
Add missing tests to .gitignore
Make the backtrace-data test helper more robust
Optionally allow unknown symbols in the backtrace tests
Move color handling into a separate header
Always use the same method to query the system page size
Check for existence of mempcpy
Move print_version into printversion.{h|c}
Include sys/types.h before fts.h
Clean up linux-specific system includes
Don't use comparison_fn_t
Avoid YESSTR and NOSTR
Add missing entries to .gitignore
Include endian.h when handling BYTE_ORDER
Add EXEEXT to gendis
Protect against integer overflow on shnum
Include strings.h to make ffs available
Avoid signed/unsigned comparison
On elf_update, remember when we mmap()
Fix nesting of braces
Make __attribute__ conditional in all installed headers
Use F_GETFD rather than F_GETFL to check validity of file descriptor
Avoid double-including config.h
Add frame pointer unwinding as fallback on x86_64
Add frame pointer unwinding for aarch64 and relax backtrace testcases.
Don't look for kernel version if not running on linux
Make elf section sorting more deterministic
signature.asc
Description: This is a digitally signed message part
Re: pending patches
Hi Ulf, On Wed, 2017-05-03 at 13:26 +0200, Ulf Hermann wrote: > My problem right now is that I have about 50 more patches pending > locally and I will be gone from May 12th to sometime in August. So, I > probably won't manage to post and fix all of them here before autumn. > Yet, I still need them for the Qt Creator (and perfparser) 4.4 > release, for which the feature freeze will happen when I'm gone. Sorry about that. Seems I planned the 0.169 release somewhat inconvenient for you. But I don't think we would have many more patches in if we had waited a week. > To deal with this, right now I have a fork of elfutils at > http://code.qt.io/cgit/qt-creator/elfutils.git/ which receives the > patches before they get here. This is not great and I want to merge it > eventually, but I can't clone myself. It looks like you have a nice setup already. But if it would be helpful to have a user branch on sourceware.org then please follow the steps in CONTRIBUTING on how to become a committer. Then even if we don't integrate all your patches in master it will look more like an "official fork" to support a Windows build. Cheers, Mark
Re: [PATCH] Drop __BEGIN_DECLS and __END_DECLS from elf.h
On Wed, 2017-05-03 at 18:03 +0200, Ulf Hermann wrote: > We don't use those anywhere else and they are not guaranteed to be > defined. Also, put the 'extern "C"' after the included headers. Note that elf.h is somewhat special. We import it as-is from glibc and like to not have divergence if at all possible. So could you try submitting to glibc upstream first? (libc-al...@sourceware.org) They might say they expect your features.h to provide these macros. But they might also just take the change as is. If not we'll figure something out for elfutils. Thanks, Mark
Re: [RFC] libdw: prepend current directory in read_srclines
Hi Torsten,
On Wed, 2017-05-03 at 22:34 +0200, Torsten Polle wrote:
> I compile the simple program relative.c:
>
> int main()
> {
> return 0;
> }
>
> with the command "gcc -g ../2017-05-03-elfutils/relative.c -o relative“.
>
> When I run systemtap with the command
> /opt/tooling/adit/systemtap/bin/stap -g -a i386 -B
> CROSS_COMPILE=i586-poky-linux- -r
> /home/polle/work/build/poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.8.12+gitAUTOINC+926c93ae07_021b4aef55-r0/build
>
> --sysroot=/home/polle/work/build/poky/build/tmp/work/qemux86-poky-linux/core-image-sato/1.0-r0/rootfs
> -L 'process("/bin/relative").function("main").call‘
>
> I get the following output:
> process("/bin/relative").function("main@../2017-05-03-elfutils/relative.c:1").call
>
> But running nm returns the following.
> nm -l | grep relative
> 080483eb T main
> /home/polle/work/issues/2017-05-03-elfutils/../2017-05-03-elfutils/relative.c:1
>
> I hope this helps.
Yes. But I think it is an systemtap issue, not an elfutils issue.
So systemtap mailinglist CCed.
If I understand the systemtap sources correctly then the above comes
from either dwarf_decl_file (Dwarf_Die *). Which returns the file name
as recorded in the DIE. If that name doesn't start with '/' then if a
full path is needed then the compile unit comp_dir needs to be prefixed:
dwarf_formstring (dwarf_attr (dwarf_diecu (die, ...), DW_AT_comp_dir, ...));
If the name already started with a '/' then it is already a full path.
It might make the systemtap output more consistent if it did that. But
since the file names are also used to match against regular expressions
you might need a bit careful where you do or don't add the full path.
Cheers,
Mark
Re: dwfl_module_addrdie fails for binaries built with clang++
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 returns nullptr, and eu-
> addr2line fails to resolve inlined frames.
>
> To reproduce this:
>[...]
>
> This also affects us in our perfparser. Not being able to find a cudie means
> not finding inlined frames nor file/line mappings, which is quite a set-back.
>
> I have noticed that backward-cpp contains a (partially) work-around for this:
>
> https://github.com/bombela/backward-cpp/blob/master/backward.hpp#L1216
O urgh how utterly broken (not backward-cpp, but the bogus DWARF clang
generates). As that comment says:
// Sadly clang does not generate the section .debug_aranges,
thus
// dwfl_module_addrdie will fail early. Clang doesn't either set
// the lowpc/highpc/range info for every compilation unit.
//
// So in order to save the world:
// for every compilation unit, we will iterate over every single
// DIEs. Normally functions should have a lowpc/highpc/range, which
// we will use to infer the compilation unit.
// note that this is probably badly inefficient.
And indeed having to scan through every CU to find a matching function
DIE is badly inefficient :{
> Is this the right approach and also what the 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 for reporting this. I think this might be the same issue seen
here: https://sourceware.org/bugzilla/show_bug.cgi?id=21247
... or at least it seems related. The function/address not found in that
case also comes from a CU generated by clang. It does have a lowpc and
ranges, but the lowpc looks bogus (zero) and the ranges don't seem to
cover the function in question. So it seems even worse than your example
where there are no lowpc/ranges. We cannot even trust them if they are
there. Sigh.
I have to think about how to handle this. We clearly need something that
just ignores the lowpc/highpc/ranges on CUs and parses every CU till the
function/address DIE is found to know which CU and line_table to use.
But that is so inefficient that I don't want to do that by default.
Cheers,
Mark
[Bug tools/21247] addr2line doesn't properly resolve filename/lineno
https://sourceware.org/bugzilla/show_bug.cgi?id=21247 --- Comment #4 from Mark Wielaard --- Looking at the debug_info we do have: [39ca09]subprogram low_pc (addr) +0x002c08b0 <_Z20PlatformCrashHandleriP9siginfo_tPv> high_pc (addr) +0x002c0a05 lo_user+0x1fe7 (flag) Yes frame_base (block1) [ 0] reg7 MIPS_linkage_name(strp) "_Z20PlatformCrashHandleriP9siginfo_tPv" name (strp) "PlatformCrashHandler" decl_file(data1) 107 decl_line(data2) 580 external (flag) Yes lo_user+0x1fe1 (flag) Yes Which is inside a compile_unit generated by clang: [29d634] compile_unit producer (strp) "clang version 3.7.1 (tags/RELEASE_371/fi nal)" language (data2) C_plus_plus (4) name (strp) "-" stmt_list(data4) 581678 comp_dir (strp) "/home/marat/production/ue4/Engine/Source " lo_user+0x1fe1 (flag) Yes low_pc (addr) +00 ranges (data4) range list [ c92e0] Note that the low_pc seems bogus (zero). And the range list seems bogus too (it consists of 800+ entries some of which look bogus too (+0x0001..+0x0001) and none seem to actually cover that function addresses. See also this discussion on the mailinglist: https://sourceware.org/ml/elfutils-devel/2017-q2/msg00190.html -- You are receiving this mail because: You are on the CC list for the bug.
Re: windows patches
Hi Ulf, On Thu, 2017-05-04 at 18:56 +0200, Ulf Hermann wrote: > all patches I consider suitable for upstream right now have been > posted here now. With all of them applied you still don't get useful > elfutils on windows, as for example the date preservation in some of > the tools doesn't work. I have more patches that just blatantly drop > functionality I don't need in order to make things work. I don't think > you want those and in fact I'm fairly sure I'm stretching it already, > so I'll stop here. > > I might come back with more patches when I find a better solution to > the remaining issues. Thanks a lot for all your work and posting the patches. I will go through them next week. I quickly scanned some just now. Some seem fine to go in. But others are a bit more iffy. I think some should really go towards gnulib if we are going to use that anyway so other projects get the same portability benefits. And I do worry a bit about others, like the O_BINARY one for example that patches every open call. That seems impossible to properly maintain and is clearly intended for a platform that is really not even POSIX/Unix-like. Cheers, Mark
don't run elfutils as root in ABRT
Hello, I work on ABRT improvement in order to increase security related to core backtrace generating using elfutils library. Here is a short description of my problem: Goal is to not call base code in elfutils and gdb functions under root. If you are more interested you can read more there: https://github.com/abrt/abrt/issues/890 We need root for opening /proc files only. First, we open these files under root, then we drop capabilities & privileges and finally, we generate core_backtrace. We have one problem that still persists, we need to pass the opened /proc/[tid]/mem file to this function: dwfl_linux_proc_find_elf Because this function opens the /proc/[tid]/mem file itself, thus it is hard coded and we cannot pass our /proc/[tid]/mem file pointer: https://github.com/abrt/satyr/blob/master/lib/core_unwind_elfutils.c#L246 So we dont know how to pass the opened file to this function. Do you have any idea how to pass the open file descriptor into the function? Or what is the best way how to achieve this? Thank you
Re: don't run elfutils as root in ABRT
Hi - On Fri, May 05, 2017 at 06:25:30PM +0200, Adam Šulc wrote: > [...] > Do you have any idea how to pass the open file descriptor into the > function? Or what is the best way how to achieve this? Via file name "/dev/fd/232" ? - FChE
