[Bug default/24328] New: [dwz] Combining files with different pointer sizes switches off multifile mode

[Bug default/24328] New: [dwz] Combining files with different pointer sizes switches off multifile mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

            Bug ID: 24328
           Summary: [dwz] Combining files with different pointer sizes
                    switches off multifile mode
           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: ---

Consider 64-bit and 32-bit hello world executables:
...
$ gcc hello.c -g -m64 -o 1; cp 1 2
$ gcc hello.c -g -m32 -o 3; cp 3 4
...

When running dwz in multifile mode, we get:
...
$ dwz -m 5 1 2 3 4
dwz: Multi-file optimization not allowed for differentpointer sizes or
endianity
$ echo $?
0
...

It seems multifile mode is switched off completely:
...
$ readelf -S 1 2 3 4 | grep -c "\.gnu_debugaltlink"
0
...

It could at least support one pointer size.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> Created attachment 11667 [details]
> Tentative patch

With this patch, we run into PR24341 for this example:
...
$ cp ../hello-64 1
$ cp ../hello-32 3 
$ cp ../hello-32 4
$ dwz -m 5 1 3 4
dwz: Multi-file optimization not allowed for different pointer sizes, skipping
3 with pointer size 4
dwz: Multi-file optimization not allowed for different pointer sizes, skipping
4 with pointer size 4
dwz: 5: .debug_info section not present
...

Another problem is that given that the first file determines the the multifile
pointer size, so 32-bit, there's no point in running in multifile mode because
the other 2 files are 64-bit, so incompatible with the multifile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 11667
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11667&action=edit
Tentative patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

Martin Liska <mliska at suse dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mliska at suse dot cz

--- Comment #3 from Martin Liska <mliska at suse dot cz> ---
Hi Tom.

I would like to remind this issue. I believe we can benefit from it as there
are packages that combine different pointer sizes:

firescope.log:[   50s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity
gcc10.log:[10958s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity
gcc7.log:[ 5609s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity
gcc9.log:[ 3210s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity
kernel-debug.log:[12564s] dwz: Multi-file optimization not allowed for
different pointer sizes or endianity
kernel-default.log:[ 2057s] dwz: Multi-file optimization not allowed for
different pointer sizes or endianity
kernel-kvmsmall.log:[ 1163s] dwz: Multi-file optimization not allowed for
different pointer sizes or endianity
kernel-vanilla.log:[ 1432s] dwz: Multi-file optimization not allowed for
different pointer sizes or endianity
lmms.log:[ 1200s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity
rr.log:[  112s] dwz: Multi-file optimization not allowed for different pointer
sizes or endianity
valgrind.log:[  736s] dwz: Multi-file optimization not allowed for different
pointer sizes or endianity

About multifile mode: I would print warning for a situation where just a single
shared library (or executable)
is provided for a pointer width.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
dwz could simply partition the inputs into multiple groups and create multiple
common debuginfo blobs.  Of course the invoker could do that processing as
well.

There's also multi-arch, not only multi-pointer-size if you for example try to
compress files of a cross compiler build with host executables and target
libraries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

--- Comment #5 from Jakub Jelinek <jakub at redhat dot com> ---
The invoker needs to tell dwz the name of the file, so if there are multiple,
it would need to tell multiple names and the question would be how to figure
out what should go where.

I think this is something that should be done in rpm scripts instead, find out
the separate sets, choose the supplemental name for each set, run dwz multiple
times on them and make sure it is all packaged.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> The invoker needs to tell dwz the name of the file, so if there are
> multiple, it would need to tell multiple names and the question would be how
> to figure out what should go where.
> 
> I think this is something that should be done in rpm scripts instead, find
> out the separate sets, choose the supplemental name for each set, run dwz
> multiple times on them and make sure it is all packaged.

Agreed.  Maybe dwz can "help" by providing

dwz --can-multifile FILE1 FILE2

and based on $? the script can do the partitioning?  Even its current
diagnostic could be abused for this if there was a --dry-run, then
the script could throw all files at dwz and filter out all inputs
that were diagnosed, repeating with those.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/24328] [dwz] Combining files with different pointer sizes switches off multifile mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24328

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> The invoker needs to tell dwz the name of the file, so if there are
> multiple, it would need to tell multiple names and the question would be how
> to figure out what should go where.

Or, the other way around, let dwz generate those names by adding a .p8/.p4
suffix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.