* [Bug default/24468] New: dwz -m generates partial unit without import
@ 2019-01-01 0:00 vries at gcc dot gnu.org
2019-01-01 0:00 ` [Bug default/24468] " vries at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 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
Bug ID: 24468
Summary: dwz -m generates partial unit without import
Product: dwz
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: default
Assignee: nobody at sourceware dot org
Reporter: vries at gcc dot gnu.org
CC: dwz at sourceware dot org
Target Milestone: ---
Say we make hello and dwz -m it:
...
$ rm -f hello
$ make hello
cc /data/dwz/dwz.git/testsuite/dwz.tests/hello.c -o hello -g
$ cp hello 1; cp 1 2; ./dwz -m 3 1 2
...
In the original hello, we find long double in elf-init.c, as printed by gdb
info types:
...
$ gdb hello -ex "info types" -batch | egrep "long double|^File"
File /data/dwz/dwz.git/testsuite/dwz.tests/hello.c:
File /usr/include/bits/types.h:
File /usr/include/libio.h:
File /usr/lib64/gcc/x86_64-suse-linux/7/include/stddef.h:
File elf-init.c:
typedef long double;
File init.c:
...
but in the dwz-m optimized 1, it's no longer there:
...
$ 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>:
...
Grepping the import tree:
...
$ readelf -w 1 > READELF
$ grep '<.*>:.*DW_TAG_partial_unit' READELF
<0><b>: Abbrev Number: 31 (DW_TAG_partial_unit)
<0><b>: Abbrev Number: 14 (DW_TAG_partial_unit)
<0><43>: Abbrev Number: 14 (DW_TAG_partial_unit)
<0><69>: Abbrev Number: 14 (DW_TAG_partial_unit)
<0><2b5>: Abbrev Number: 14 (DW_TAG_partial_unit)
<0><33b>: Abbrev Number: 14 (DW_TAG_partial_unit)
$ grep 'DW_AT_import.*:' READELF
<15> DW_AT_import : <alt 0xb>
<1a> DW_AT_import : <alt 0x33b>
<6b> DW_AT_import : <0xb> [Abbrev Number: 31]
<d0> DW_AT_import : <alt 0x43>
<d5> DW_AT_import : <alt 0x69>
<da> DW_AT_import : <0xb> [Abbrev Number: 31]
<2e0> DW_AT_import : <alt 0x43>
<2e5> DW_AT_import : <alt 0x33b>
...
we find a partial unit at 2b5 that is not imported anywhere.
And indeed, that's the one defining long double:
...
Compilation Unit @ offset 0x2aa:
Length: 0x82 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><2b5>: Abbrev Number: 14 (DW_TAG_partial_unit)
<2b6> DW_AT_stmt_list : 0x0
<2ba> DW_AT_comp_dir : (indirect string, offset: 0x635):
/home/abuild/rpmbuild/BUILD/glibc-2.26/csu
...
<1><2ca>: Abbrev Number: 24 (DW_TAG_base_type)
<2cb> DW_AT_byte_size : 16
<2cc> DW_AT_encoding : 4 (float)
<2cd> DW_AT_name : (indirect string, offset: 0x403): 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
* [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
@ 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
end of thread, other threads:[~2019-04-23 12:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).