Re: frame unwinding patches
On Thursday, February 16, 2017 12:33:27 AM CEST Mark Wielaard wrote: > Hi, > > I put all three frame pointer unwinding fallback patches on > the mjw/fp-unwind branch. I'll also sent them to the list using > git send-mail --annotate taking out the binary file patches. > Hopefully that will make them appear on the list, bypassing the > spam filters. > > [PATCH 1/3] Add frame pointer unwinding as fallback on x86_64 > [PATCH 2/3] Add frame pointer unwinding as fallback on arm > [PATCH 3/3] Add frame pointer unwinding for aarch64 > > I had to hand apply a few things because of whitespace adjustments. > Hopefully I did it right and this is how Ulf intended the patches. > If not, my apologies, and please let me know what changes you did > intend. Ping? Any progress on merging this functionality upstream? It can make quite a difference in unwinding. I just got a report from a colleague. As-is, elfutils would fail to unwind from the following location in his application: 0x1137ca4 With the x86_64 patch applied, he got a proper backtrace: 0x1137ca4 0xc45466 0xc4fffa 0xda76f3 0xd78181 0xd8069c 0xd846bd 0xd995b7 QOpenGLFunctions::glTexImage2D qopenglfunctions.h:1022 ... So, please consider reviewing and merging this. Thanks -- Milian Wolff m...@milianw.de http://milianw.de
Re: frame unwinding patches
Ping? Any progress on merging this functionality upstream? It can make quite a difference in unwinding. The patches have also been in perfparser releases for over a year now. I would like to see them upstream. best, Ulf
[Bug libelf/21315] multiple misaligned address errors for Elf64_Shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=21315 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- Note that in some cases elfutils deliberately does unaligned accesses if it believes it is safe. See the following in lib/eu-config.h: /* Define ALLOW_UNALIGNED if the architecture allows operations on unaligned memory locations. */ #define SANITIZE_UNDEFINED 1 #if (defined __i386__ || defined __x86_64__) && ! CHECK_UNDEFINED # define ALLOW_UNALIGNED1 #else # define ALLOW_UNALIGNED0 #endif Note that it is to not allow unaligned accesses when configuring with --enable-sanitize-undefined (which adds -fsanitize=undefined -fno-sanitize-recover to CFLAGS and CXXFLAGS). Are you configuring using --enable-sanitize-undefined? Or adding -fsanitize=undefined by hand? In the later case you should also add -DCHECK_UNDEFINED=1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/21315] multiple misaligned address errors for Elf64_Shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=21315 --- Comment #2 from Agostino Sarubbo --- (In reply to Mark Wielaard from comment #1) > Note that in some cases elfutils deliberately does unaligned accesses if it > believes it is safe. See the following in lib/eu-config.h: > > /* Define ALLOW_UNALIGNED if the architecture allows operations on >unaligned memory locations. */ > #define SANITIZE_UNDEFINED 1 > #if (defined __i386__ || defined __x86_64__) && ! CHECK_UNDEFINED > # define ALLOW_UNALIGNED1 > #else > # define ALLOW_UNALIGNED0 > #endif > > Note that it is to not allow unaligned accesses when configuring with > --enable-sanitize-undefined (which adds -fsanitize=undefined > -fno-sanitize-recover to CFLAGS and CXXFLAGS). > > Are you configuring using --enable-sanitize-undefined? Or adding > -fsanitize=undefined by hand? In the later case you should also add > -DCHECK_UNDEFINED=1 It was added by hand..I need to test if I obtain those warning with --enable-sanitize-undefined -- You are receiving this mail because: You are on the CC list for the bug.
Re: frame unwinding patches
On Mon, Apr 03, 2017 at 11:02:53AM +0200, Ulf Hermann wrote: > > Ping? Any progress on merging this functionality upstream? > > It can make quite a difference in unwinding. > > The patches have also been in perfparser releases for over a year now. I > would like to see them upstream. Yes, sorry. The patches looked fine. Then I thought I should try adding similar support to another arch to double check. And then I got distracted by something else. I'll get back to is asap and make sure they get in before the next release end of the month. Cheers, Mark
Re: frame unwinding patches
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: > > 0x1137ca4 > > With the x86_64 patch applied, he got a proper backtrace: S/he has something wrong with the compiler. With -fasynchronous-unwind-tables frame pointer unwinding is never needed and gcc defaults to -fasynchronous-unwind-tables on x86_64. This is why I haven't implemented it originally as it only paper overs the real problem and it leads to unreliable backtraces in longterm. Jan
[Bug tools/21299] heap-based buffer overflow in handle_gnu_hash (readelf.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21299 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit 9d84fdd78705d7a1b9947a9f4ca77fbccdd76d4a Author: Mark Wielaard Date: Fri Mar 24 12:15:02 2017 +0100 readelf: Fix off by one sanity check in handle_gnu_hash. We sanity check to make sure we don't index outside the chain array by testing inner > max_nsyms. But inner is a zero-based index, while max_nsyms is the maximum number. Change the check to inner >= max_nsyms. https://sourceware.org/bugzilla/show_bug.cgi?id=21299 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21300] heap-based buffer overflow in ebl_object_note_type_name (eblobjnotetypename.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21300 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit b0b58c5e0b34e54194aa042f2310af58ee7de603 Author: Mark Wielaard Date: Fri Mar 24 14:10:26 2017 +0100 Use the empty string for note names with zero size (without any data). ELF notes can have a zero sized name. In which case there is no data at all (so also no zero terminator). Make sure to use the empty string for such notes if the code does not otherwise explicitly check n_namesz. https://sourceware.org/bugzilla/show_bug.cgi?id=21300 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/21301] memory allocation failure in __libelf_decompress
https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit 8dcc4bf791469a32c3a09ebcc23b309bf75c795f Author: Mark Wielaard Date: Fri Mar 24 15:06:04 2017 +0100 libelf: Check compression ratio before trying to allocate output buffer. The maximum compression factor (http://www.zlib.net/zlib_tech.html) is 1032:1. Add a sanity check for that before trying to allocate lots of memory and trying to decompress lots of bogus data. https://sourceware.org/bugzilla/show_bug.cgi?id=21301 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/21199] elf_update might "fill" over existing section data
https://sourceware.org/bugzilla/show_bug.cgi?id=21199 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit a3bf8f0852d0f66911dcf879c5a1fcff3cb4cb46 Author: Mark Wielaard Date: Mon Mar 27 17:01:57 2017 +0200 libelf: Always update last_offset in updatefile and updatemmap. When ELF section data was used, but not updated or marked as dirty and there also existed non-dirty sections and some padding was needed between the sections (possibly because of alignment) then elf_update might write "fill" over some of the existing data. This happened because in that case the last_position was not updated correctly. Includes a new testcase fillfile that fails before this patch by showing fill instead of the expected data in some section data. It succeeds with this patch. https://sourceware.org/bugzilla/show_bug.cgi?id=21199 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21310] eu-elflint: heap-based buffer overflow in check_symtab_shndx (elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21310 --- Comment #2 from Mark Wielaard --- commit 9a0d9d314a6342b56e3277bd7ad7ecb6e73a7d38 Author: Mark Wielaard Date: Mon Mar 27 23:59:02 2017 +0200 elflint: Check symbol table data is big enough before checking. Before checking symbol index zero we should make sure the data size is big enough. https://sourceware.org/bugzilla/show_bug.cgi?id=21310 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21311] eu-elflint: heap-based buffer overflow in check_sysv_hash (elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21311 --- Comment #2 from Mark Wielaard --- commit 61fe61898747f63eb35a81c2261f3590a3dab8fd Author: Mark Wielaard Date: Tue Mar 28 00:38:52 2017 +0200 elflint: Don't trust sh_entsize when checking hash sections. Calculate and use the expected entsize instead of relying on the one given by the ELF file section header. Return early if there isn't enough data in the section to check the full hash table. https://sourceware.org/bugzilla/show_bug.cgi?id=21311 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21312] eu-elflint: memory allocation failure in xcalloc (xmalloc.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21312 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit 4314716cd498bb51639db717bd7ce6182de33322 Author: Mark Wielaard Date: Tue Mar 28 01:25:34 2017 +0200 elflint: Sanity check the number of phdrs and shdrs available. Make sure we can at least read the shnum sections or phnum segments. Limit the number we do check to those we can actually read. https://sourceware.org/bugzilla/show_bug.cgi?id=21312 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21320] eu-elflint: heap-based buffer overflow in check_group (elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21320 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit fb6709f1a41b58a9557ea45b7f53ae678c660b21 Author: Mark Wielaard Date: Tue Mar 28 13:33:03 2017 +0200 elflint: Don't check section group without flags word. https://sourceware.org/bugzilla/show_bug.cgi?id=21320 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21310] eu-elflint: heap-based buffer overflow in check_symtab_shndx (elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21310 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- Pushed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/21311] eu-elflint: heap-based buffer overflow in check_sysv_hash (elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=21311 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- Pushed -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #6 from Luiz Angelo Daros de Luca --- Mark, I know that both might be a compiler bug. However, the cost of solving them are very low. Yes, I might be compiling elfutils with non-standard options. However, the non-standard might be the standard for some distribution like LEDE/OpenWRT. The alternative for me is not to use -Wno-error but to patch the code (and maintain the patch) until compiler gets it right. I was just hoping that fixing this upstream will help any other elfutils users that need to compile with those non-standard flags on. I'll reopen only once more this bug. If you think that it should not be "fixed" upstream, mark it again as resolved and I'll let it go. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 --- Comment #5 from Luiz Angelo Daros de Luca --- Mark, I know that both might be a compiler bug. However, the cost of solving them are very low. Yes, I might be compiling elfutils with non-standard options. However, the non-standard might be the standard for some distribution like LEDE/OpenWRT. The alternative for me is not to use -Wno-error but to patch the code (and maintain the patch) until compiler gets it right. I was just hoping that fixing this upstream will help any other elfutils users that need to compile with those non-standard flags on. I'll reopen only once more this bug. If you think that it should not be "fixed" upstream, mark it again as resolved and I'll let it go. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/21011] "may be used uninitialized" error with -Werror=maybe-uninitialized
https://sourceware.org/bugzilla/show_bug.cgi?id=21011 Luiz Angelo Daros de Luca changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from Luiz Angelo Daros de Luca --- returning to unconfirmed. -- You are receiving this mail because: You are on the CC list for the bug.
