* [Bug default/24468] dwz -m generates partial unit without import
2019-01-01 0:00 [Bug default/24468] New: dwz -m generates partial unit without import vries at gcc dot gnu.org
@ 2019-01-01 0:00 ` vries at gcc dot gnu.org
2019-01-01 0:00 ` vries at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: vries at gcc dot gnu.org @ 2019-01-01 0:00 UTC (permalink / raw)
To: dwz
https://sourceware.org/bugzilla/show_bug.cgi?id=24468
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed:
https://sourceware.org/git/?p=dwz.git;a=commit;h=4fc00777a00e0b322810f5a67d62f73b646ed479
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug default/24468] dwz -m generates partial unit without import
2019-01-01 0:00 [Bug default/24468] New: dwz -m generates partial unit without import vries at gcc dot gnu.org
2019-01-01 0:00 ` [Bug default/24468] " vries at gcc dot gnu.org
@ 2019-01-01 0:00 ` vries at gcc dot gnu.org
2019-01-01 0:00 ` vries at gcc dot gnu.org
2019-01-01 0:00 ` vries at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: vries at gcc dot gnu.org @ 2019-01-01 0:00 UTC (permalink / raw)
To: dwz
https://sourceware.org/bugzilla/show_bug.cgi?id=24468
--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> ...
> diff --git a/dwz.c b/dwz.c
> index 8ea7c4d..93532b9 100644
> --- a/dwz.c
> +++ b/dwz.c
> @@ -3161,7 +3161,7 @@ die_eq_1 (dw_cu_ref cu1, dw_cu_ref cu2,
> switch (form1)
> {
> case DW_FORM_ref_addr:
> - if (likely (!op_multifile && !rd_multifile))
> + if (likely (!op_multifile && !rd_multifile && !fi_multifile))
> {
> if (form1 != form2)
> FAIL;
> @@ -3176,7 +3176,7 @@ die_eq_1 (dw_cu_ref cu1, dw_cu_ref cu2,
> switch (form2)
> {
> case DW_FORM_ref_addr:
> - if (likely (!op_multifile && !rd_multifile))
> + if (likely (!op_multifile && !rd_multifile && !fi_multifile))
> FAIL;
> break;
> case DW_FORM_ref_udata:
> ...
Interestingly, the code following this that forces handling unequal DW_FORMs
has the same condition:
...
case DW_FORM_ref_addr:
if (likely (!op_multifile && !rd_multifile && !fi_multifile))
{
ptr1 += cu1->cu_version == 2 ? ptr_size : 4;
ptr2 += cu2->cu_version == 2 ? ptr_size : 4;
break;
}
/* FALLTHRU */
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug default/24468] dwz -m generates partial unit without import
2019-01-01 0:00 [Bug default/24468] New: dwz -m generates partial unit without import vries at gcc dot gnu.org
2019-01-01 0:00 ` [Bug default/24468] " vries at gcc dot gnu.org
2019-01-01 0:00 ` vries at gcc dot gnu.org
@ 2019-01-01 0:00 ` vries at gcc dot gnu.org
2019-01-01 0:00 ` vries at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: vries at gcc dot gnu.org @ 2019-01-01 0:00 UTC (permalink / raw)
To: dwz
https://sourceware.org/bugzilla/show_bug.cgi?id=24468
--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
So, what happens is this: the partial unit at 2b5 in the multifile contains as
first die:
...
<1><2be>: Abbrev Number: 5 (DW_TAG_const_type)
<2bf> DW_AT_type : <0x4c>
...
which refers to:
...
<1><4c>: Abbrev Number: 18 (DW_TAG_typedef)
<4d> DW_AT_name : (indirect string, offset: 0x54c): size_t
<51> DW_AT_decl_file : 1
<52> DW_AT_decl_line : 216
<53> DW_AT_type : <0x344>
...
in another partial unit in the multifile.
When matching dies in the input file against the dies in the multifile during
finalize_multifile, we compare 2be to 394:
...
<1><389>: Abbrev Number: 24 (DW_TAG_typedef)
<38a> DW_AT_name : (indirect string, offset: 0x226): size_t
<38e> DW_AT_decl_file : 2
<38f> DW_AT_decl_line : 216
<390> DW_AT_type : <0x14>
<1><394>: Abbrev Number: 7 (DW_TAG_const_type)
<395> DW_AT_type : <0x389>
...
which then fails because of a mismatch in DW_FORM (DW_FORM_ref_addr vs
DW_FORM_ref_udata).
OTOH, the long double die in the input file matches the one in the multifile.
Subsequently, we hit this in create_import_tree, and skip generating an import
for the partial unit due to 2be not having a duplicate:
...
if (unlikely (fi_multifile) && rdie->die_nextdup == NULL)
{
pu->u1.cu_icu = NULL;
continue;
}
...
OTOH, we need an import for the partial unit due to the long double, which does
have a duplicate.
Tentative patch:
...
@@ -5779,10 +5798,15 @@ create_import_tree (void)
for (rdie = pu->cu_die->die_child;
rdie->die_named_namespace; rdie = rdie->die_child)
;
- if (unlikely (fi_multifile) && rdie->die_nextdup == NULL)
+ if (unlikely (fi_multifile))
{
- pu->u1.cu_icu = NULL;
- continue;
+ while (rdie->die_nextdup == NULL && rdie->die_sib)
+ rdie = rdie->die_sib;
+ if (rdie->die_nextdup == NULL)
+ {
+ pu->u1.cu_icu = NULL;
+ continue;
+ }
}
npus++;
if (pu->cu_version > new_pu_version)
...
Using the tentative patch, we get the missing import in CU elf-init.c:
...
<1><2e4>: Abbrev Number: 15 (DW_TAG_imported_unit)
<2e5> DW_AT_import : <alt 0x2b5>
...
and find again the missing long double with gdb:
...
$ gdb 1 -ex "info types" -batch | egrep "long double|^File"
File /usr/include/bits/types.h:
File /usr/include/libio.h:
File /usr/lib64/gcc/x86_64-suse-linux/7/include/stddef.h:
File <unknown>:
typedef long double;
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug default/24468] dwz -m generates partial unit without import
2019-01-01 0:00 [Bug default/24468] New: dwz -m generates partial unit without import vries at gcc dot gnu.org
` (2 preceding siblings ...)
2019-01-01 0:00 ` vries at gcc dot gnu.org
@ 2019-01-01 0:00 ` vries at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: vries at gcc dot gnu.org @ 2019-01-01 0:00 UTC (permalink / raw)
To: dwz
https://sourceware.org/bugzilla/show_bug.cgi?id=24468
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> So, what happens is this: the partial unit at 2b5 in the multifile contains
> as first die:
> ...
> <1><2be>: Abbrev Number: 5 (DW_TAG_const_type)
> <2bf> DW_AT_type : <0x4c>
> ...
> which refers to:
> ...
> <1><4c>: Abbrev Number: 18 (DW_TAG_typedef)
> <4d> DW_AT_name : (indirect string, offset: 0x54c): size_t
> <51> DW_AT_decl_file : 1
> <52> DW_AT_decl_line : 216
> <53> DW_AT_type : <0x344>
> ...
> in another partial unit in the multifile.
>
> When matching dies in the input file against the dies in the multifile
> during finalize_multifile, we compare 2be to 394:
> ...
> <1><389>: Abbrev Number: 24 (DW_TAG_typedef)
> <38a> DW_AT_name : (indirect string, offset: 0x226): size_t
> <38e> DW_AT_decl_file : 2
> <38f> DW_AT_decl_line : 216
> <390> DW_AT_type : <0x14>
> <1><394>: Abbrev Number: 7 (DW_TAG_const_type)
> <395> DW_AT_type : <0x389>
> ...
> which then fails because of a mismatch in DW_FORM (DW_FORM_ref_addr vs
> DW_FORM_ref_udata).
>
which is fixed by:
...
diff --git a/dwz.c b/dwz.c
index 8ea7c4d..93532b9 100644
--- a/dwz.c
+++ b/dwz.c
@@ -3161,7 +3161,7 @@ die_eq_1 (dw_cu_ref cu1, dw_cu_ref cu2,
switch (form1)
{
case DW_FORM_ref_addr:
- if (likely (!op_multifile && !rd_multifile))
+ if (likely (!op_multifile && !rd_multifile && !fi_multifile))
{
if (form1 != form2)
FAIL;
@@ -3176,7 +3176,7 @@ die_eq_1 (dw_cu_ref cu1, dw_cu_ref cu2,
switch (form2)
{
case DW_FORM_ref_addr:
- if (likely (!op_multifile && !rd_multifile))
+ if (likely (!op_multifile && !rd_multifile && !fi_multifile))
FAIL;
break;
case DW_FORM_ref_udata:
...
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread