From: Aleksei Vetrov
Test dwfl-report-offline-memory against an archive that contains
non-relocatable ELFs with the same name and contents.
Signed-off-by: Aleksei Vetrov
---
tests/run-dwfl-report-offline-memory.sh | 7 +++
tests/test-ar-duplicates.a.bz2 | Bin 0 -> 783 bytes
2 f
From: Aleksei Vetrov
When archive is processed in process_archive (libdwfl/offline.c), it
creates an Elf object for each archive member. Then in
process_archive_member it calls process_file to create a Dwfl_Module
through __libdwfl_report_elf.
The ownership of the Elf object is expected to be:
From: Aleksei Vetrov
This check was initially added to test if offset overflows the safe
prefix where any string will be null-terminated. However the check
was placed in a wrong place and didn't cover all `attrp->form` cases.
* libdw/dwarf_formstring.c (dwarf_formstring): Move offset check
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #15 from Aleksei Vetrov ---
Created attachment 15213
--> https://sourceware.org/bugzilla/attachment.cgi?id=15213&action=edit
logger_write.cpp
Attaching "logger_write.cpp" and a way to reproduce binary with big
discriminator with
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #14 from Aleksei Vetrov ---
Here are investigation results on why this happens in LLVM. It is a new
algorithm for assigning "hierarchical discriminator for FSAFDO".
>From https://reviews.llvm.org/D102246:
#define BASE_DIS_BIT_B
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #12 from Aleksei Vetrov ---
(In reply to Mark Wielaard from comment #6)
> So my preferred workaround:
> https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=really-large-disc
Do you have plan to merge it to master?
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #9 from Aleksei Vetrov ---
(In reply to Frank Ch. Eigler from comment #7)
> So my preferred workaround:
I like this workaround and it works in our use case.
> appears to be based on the assumption that truncated bitfields will no
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #4 from Aleksei Vetrov ---
(In reply to Frank Ch. Eigler from comment #3)
> Is there some reason not to just bump up that bitfield width from :24 to :32
> or more for now, until a deeper analysis of llvm informs us as to how wide
>
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #1 from Aleksei Vetrov ---
Created attachment 15166
--> https://sourceware.org/bugzilla/attachment.cgi?id=15166&action=edit
liblog.so
--
You are receiving this mail because:
You are on the CC list for the bug.
Component: libdw
Assignee: unassigned at sourceware dot org
Reporter: vv at google dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Hello!
I've got a binary that have debug_line information unsupported by libdw,
be
10 matches
Mail list logo
