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.
Created attachment 11667 [details] Tentative patch
(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.
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.
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.
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.
(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.
(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.