[Bug libdw/30967] New: Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 Bug ID: 30967 Summary: Discriminator in Dwarf_Line_s may exceed 24 bits Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 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, because "discriminator" attribute exceeds 24 bit allocated for it in Dwarf_Line_s. ``` $ llvm-dwarfdump --debug-line=4453 liblog.so | grep 2013278720 0x6167 1427 22 4 02013278720 is_stmt ``` Problematic binary attached. I don't have a small test to reproduce an issue, but I'll try to create one. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
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.
[Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
https://sourceware.org/bugzilla/show_bug.cgi?id=30967 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #2 from Mark Wielaard --- Note that eu-readelf --debug-dump=info also has trouble with this (probably also because it cannot correct parse the large discriminator): $ eu-readelf --debug-dump=info ./liblog.so [...] Version: 5, Abbreviation section offset: 3225, Address size: 4, Offset size: 4 Unit type: compile (1) [ 51c9] compile_unit abbrev: 1 producer (strx1) "Android (10742551, +pgo, +bolt, +lto, + mlgo, based on r498229b) clang version 17.0.4 (https://android.googlesource.com/ toolchain/llvm-project e34ed7d63863b45858e74126edaa738e75887800)" language (data2) C_plus_plus_14 (33) name (strx1) "system/logging/liblog/logger_write.cpp" str_offsets_base (sec_offset) str offsets base [ 1198] stmt_list(sec_offset) 4453 low_pc (addr) +00 ranges (rnglistx) range index [24] addr_base(sec_offset) address base [ 1d8] rnglists_base(sec_offset) range list [ 10a] loclists_base(sec_offset) location list [ 777] [ 51e7]base_typeabbrev: 2 name (strx2) "DW_ATE_signed_32" encoding (data1) signed (5) byte_size(data1) 4 [ 51ec]base_typeabbrev: 2 name (strx2) "DW_ATE_signed_64" encoding (data1) signed (5) byte_size(data1) 8 [ 51f1]subprogram abbrev: 3 low_pc (addrx) [1a] +0x5880 <_Z13GetDefaultTagv> high_pc (data4) 114 (+0x58f2) frame_base (exprloc) [ 0] reg5 call_all_calls (flag_present) yes abstract_origin (ref4) [ 9e3d] [ 51fd] variable abbrev: 4 name (strx1) "default_tag" type (ref4) [ 5215] eu-readelf: no srcfiles for CU [51c9] decl_file(data1) ??? (0) decl_line(data1) 152 location (exprloc) [ 0] addrx [0] +0xfe58 <_ZZ13GetDefaultTagvE11default_tag> [...] Note that the CU DIE says: stmt_list(sec_offset) 4453 And there definitely is a table at offset 4453 as can be seen with eu-readelf --debug-dump=line ./liblog.so -- You are receiving this mail because: You are on the CC list for the bug.
Re: PATCH PR30962, debuginfod
Hi Frank, On Wed, 2023-10-11 at 14:57 -0400, Frank Ch. Eigler wrote: > > OK. But I think you should add an explanation or example to "Front-end > > proxies can also elide sensitive path name components" paragraph. So > > the user is fully aware what those "sensitive path names" are. Maybe > > even add that debuginfod-find -v example so people can double check. > > OK, rewrote the related text in the man page: Looks really good and informative. Thanks, Mark
[Bug debuginfod/30962] ensure x-debuginfod-file / -archive headers always return full path names
https://sourceware.org/bugzilla/show_bug.cgi?id=30962 Frank Ch. Eigler changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Ch. Eigler --- Author: Frank Ch. Eigler Date: Tue Oct 10 16:21:00 2023 -0400 PR30962: debuginfod: full paths for X-DEBUGINFOD-FILE/ARCHIVE response headers -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH 13/16] libdw: Make libdw_findcu thread-safe
Hi Heather,
On Tue, Oct 10, 2023 at 03:42:57PM +0200, Mark Wielaard wrote:
> From: Heather McIntyre
>
> * libdw/libdw_findcu.c (findcu_cb): Use eu_tsearch.
> (__libdw_findcu): Use eu_tfind and next_tucu_offset_lock.
> (__libdw_findcu_addr): Use eu_tfind.
> (__libdw_find_split_dbg_addr): Likewise.
>
> Signed-off-by: Heather S. McIntyre
> Signed-off-by: Mark Wielaard
> ---
> libdw/libdw_findcu.c | 54
> 1 file changed, 35 insertions(+), 19 deletions(-)
>
> diff --git a/libdw/libdw_findcu.c b/libdw/libdw_findcu.c
> index ed744231..e546fb0f 100644
> --- a/libdw/libdw_findcu.c
> +++ b/libdw/libdw_findcu.c
> @@ -32,9 +32,13 @@
> #endif
>
> #include
> -#include
> +#include
> #include "libdwP.h"
>
> +/* __libdw_findcu modifies "&dbg->next_tu_offset : &dbg->next_cu_offset".
> + May read or write, so mutual exclusion is enforced to prevent a race. */
> +rwlock_define(static, next_tucu_offset_lock);
> +
Could this be a per struct Dwarf lock?
> static int
> findcu_cb (const void *arg1, const void *arg2)
> {
> @@ -213,7 +217,7 @@ __libdw_intern_next_unit (Dwarf *dbg, bool debug_types)
>
> Dwarf_Sig8_Hash_insert (&dbg->sig8_hash, unit_id8, newp);
>
>/* Add the new entry to the search tree. */
> - if (tsearch (newp, tree, findcu_cb) == NULL)
> + if (eu_tsearch (newp, tree, findcu_cb) == NULL)
> {
>/* Something went wrong. Undo the operation. */
>*offsetp = oldoff;
This is OK since when __libdw_intern_next_unit is called from
__libdw_findcu the next_tucu_offset_lock is held.
But there is also a call to __libdw_intern_next_unit from
dwarf_formref_die. So there should also be a lock there?
> @@ -234,28 +238,40 @@ __libdw_findcu (Dwarf *dbg, Dwarf_Off start, bool
> v4_debug_types)
>
>/* Maybe we already know that CU. */
>struct Dwarf_CU fake = { .start = start, .end = 0 };
> - struct Dwarf_CU **found = tfind (&fake, tree, findcu_cb);
> + struct Dwarf_CU **found = eu_tfind (&fake, tree, findcu_cb);
> + struct Dwarf_CU *result = NULL;
> +
>if (found != NULL)
> return *found;
>
> - if (start < *next_offset)
> -{
> - __libdw_seterrno (DWARF_E_INVALID_DWARF);
> - return NULL;
> -}
> + rwlock_wrlock(next_tucu_offset_lock);
>
> - /* No. Then read more CUs. */
> - while (1)
> + if (start < *next_offset)
> +__libdw_seterrno (DWARF_E_INVALID_DWARF);
> + else
> {
> - struct Dwarf_CU *newp = __libdw_intern_next_unit (dbg, v4_debug_types);
> - if (newp == NULL)
> - return NULL;
> + /* No. Then read more CUs. */
> + while (1)
> + {
> + struct Dwarf_CU *newp = __libdw_intern_next_unit (dbg,
> + v4_debug_types);
> + if (newp == NULL)
> + {
> + result = NULL;
> + break;
> + }
>
> - /* Is this the one we are looking for? */
> - if (start < *next_offset || start == newp->start)
> - return newp;
> + /* Is this the one we are looking for? */
> + if (start < *next_offset || start == newp->start)
> + {
> + result = newp;
> + break;
> + }
> + }
> }
> - /* NOTREACHED */
> +
> + rwlock_unlock(next_tucu_offset_lock);
> + return result;
> }
This look OK.
> struct Dwarf_CU *
> @@ -283,7 +299,7 @@ __libdw_findcu_addr (Dwarf *dbg, void *addr)
> return NULL;
>
>struct Dwarf_CU fake = { .start = start, .end = 0 };
> - struct Dwarf_CU **found = tfind (&fake, tree, findcu_cb);
> + struct Dwarf_CU **found = eu_tfind (&fake, tree, findcu_cb);
>
>if (found != NULL)
> return *found;
> @@ -298,7 +314,7 @@ __libdw_find_split_dbg_addr (Dwarf *dbg, void *addr)
>/* XXX Assumes split DWARF only has CUs in main IDX_debug_info. */
>Elf_Data fake_data = { .d_buf = addr, .d_size = 0 };
>Dwarf fake = { .sectiondata[IDX_debug_info] = &fake_data };
> - Dwarf **found = tfind (&fake, &dbg->split_tree, __libdw_finddbg_cb);
> + Dwarf **found = eu_tfind (&fake, &dbg->split_tree, __libdw_finddbg_cb);
>
>if (found != NULL)
> return *found;
OK.
Thanks,
Mark
Re: [PATCH 14/16] libdw,libdwfl: Use eu-search for thread-safety
Hi Heather, On Tue, Oct 10, 2023 at 03:42:58PM +0200, Mark Wielaard wrote: > > * libdw/cie.c: Add eu-search.h and remove search.h. > Change calls of tsearch/tfind to eu_tsearch/eu_tfind. > * libdw/dwarf_getlocation.c: Likewise. > * libdw/dwarf_getmacros.c: Likewise. > * libdw/dwarf_getsrclines.c: Likewise. > * libdw/fde.c: Likewise. > * libdwfl/cu.c: Likewise. These all look good. Just have to think about whether the global static lock currently used in eu-search is the right approach. Cheers, Mark
Re: [PATCH 16/16] configure: No longer mark --enable-thread-safety as EXPERIMENTAL
Hi Heather, On Tue, Oct 10, 2023 at 03:43:00PM +0200, Mark Wielaard wrote: > > * configure.ac (--enable-thread-safety): Remove experimental > warning. > This all looks good. We should push this once we have all libelf fixes in. BTW. Your original ChangeLog entry also mentioned a NEWS change, but that wasn't in your original patch. Cheers, Mark
