Binutils causes abnormally large, non-working binaries since 2.43

[Jan Beulich]

On 17.02.2025 18:35, Bastiaan Timmer wrote:
> Again apologies, I keep forgetting to hit "reply all" instead of just 
> "reply". However, this time this message is also updated with some more 
> info:
> 
> Thanks you for your thorough reply. It looks like you are onto 
> something: I've compiled binutils-2.43 with just that commit undone, and 
> all sizes seem to be back to normal.
> 
> Contrary to what I mentioned in my previous (accidentally private) 
> message, this also solves the problem of executables linked to this 
> package not working: this change seems to solve everything. I've updated 
> the github page I made for this with this new information, including a 
> diff: 
> https://github.com/bepaald/binutils_issue/tree/main?tab=readme-ov-file#update
> 
> Of course I do not know the intended use for this particular commit, so 
> I won't suggest reverting it, maybe it simply needs fixing. But I'm well 
> out of my depth here, so I hope someone else can pick up, though I'm 
> more than willing to follow any instructions if I can help in any way.

That commit touching objcopy.c only (as to what's relevant for the writing
of object files), there must be a use of objcopy or strip somewhere. The
build logs you provided, however, don't have any indication thereof. Gcc
would use objcopy when passed -gsplit-dwarf, but that doesn't even look to
be potentially applicable here (iirc split debug info is only an option
with ELF).

Further I tried both Cygwin and MinGW objcopy on a random (small) object,
without passing any --section-alignment option of course. That didn't
change the object at all. If I pass --section-alignment, I can see the
provided value taking effect. I wonder whether that's really intended for
COFF objects; it looks to me as if it's solely intended for COFF/PE
binaries.

Would you mind trying with the simple patch below? If that makes a
difference, we'd then still need to understand how objcopy (or strip)
comes into play here in the first place. Depending on where it's used and
how, this or another change may be warranted.

Jan

--- a/binutils/objcopy.c
+++ b/binutils/objcopy.c
@@ -4301,7 +4301,8 @@ setup_section (bfd *ibfd, sec_ptr isecti
     alignment = p->alignment;
   else if (pe_section_alignment != (bfd_vma) -1
 	   && bfd_get_flavour (ibfd) == bfd_target_coff_flavour
-	   && bfd_get_flavour (obfd) == bfd_target_coff_flavour)
+	   && bfd_get_flavour (obfd) == bfd_target_coff_flavour
+	   && bfd_pei_p (obfd))
     {
       alignment = power_of_two (pe_section_alignment);
 


> On 17-02-2025 14:08, Dimitry Andric wrote:
>> My first guess would be https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=121a3f4b4f4aac216abe239f6f3bd491b63e5e34, "Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections". But I'm unsure whether the build process for this openssl package is using objcopy.
>>
>> -Dimitry
>>
>