Bug 2234396

Summary:	internal error in add_output_section_to_load after binutils 2.41 update
Product:	[Fedora] Fedora	Reporter:	Nikita Popov <npopov>
Component:	binutils	Assignee:	Nick Clifton <nickc>
Status:	CLOSED COMPLETED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	amodra, dvlasenk, fweimer, jakub, nickc, sipoyare, tuliom, yahmad
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	binutils-2.41-5.fc40	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-14 14:28:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nikita Popov 2023-08-24 10:00:18 UTC

After the binutils 2.41 update that landed in rawhide yesterday, the test https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/gold/PowerPC/mtriple.ll in the LLVM test suite started failing with:

/usr/bin/ld.gold: internal error in add_output_section_to_load, at ../../gold/output.cc:4097

This is either a bug in binutils or a previously not exposed problem in the LLVM gold plugin.

Reproducible: Always

Comment 1 Nikita Popov 2023-08-24 11:02:02 UTC

Steps to reproduce without the LLVM test suite:

Create test.ll with:

target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"

Then run:

dnf install llvm
llvm-as < test.ll > test.o
ld.gold -plugin /usr/lib64/LLVMgold.so -m elf32ppc -plugin-opt=mtriple=powerpc-linux-gnu -shared test.o -o test

Results in:

ld.gold: internal error in add_output_section_to_load, at ../../gold/output.cc:4097

Comment 2 Tulio Magno Quites Machado Filho 2023-08-24 12:27:35 UTC

While I agree that ld.gold should not throw the internal error, I wonder if this is also a broken test..

What is it trying to accomplish?
Is it testing if a ppc64 object can be linked into a ppc32 shared object?
Is this really a valid test?

By the way, this links successfully into a powerpc64-linux-gnu shared object.

Comment 3 Nikita Popov 2023-08-24 13:13:54 UTC

I don't think that's what this is doing. We can get rid of the weird triple switching and start of with this test.ll:

target datalayout = "E-m:e-p:32:32-Fn32-i64:64-n32"
target triple = "powerpc-unknown-linux-gnu"

and then:

llvm-as < test.ll > test.o
ld.gold -plugin /usr/lib64/LLVMgold.so -m elf32ppc -shared test.o -o test

This is just linking a ppc32 shared object with ppc64 not being involved.

It works without -shared and also if ld.gold is replaced by ld.bfd.

----

It looks like this can also be reproduced without the LLVM gold plugin. This fails in the same way:

llc -filetype=obj < test.ll > test.o
ld.gold -m elf32ppc -shared test.o -o test

(llc just produces a normal ELF object here, rather than the LTO object that llvm-as produces.)

Comment 4 Nick Clifton 2023-08-24 13:33:54 UTC

In fact it seems that llvm is not needed at all, as the same bug can be reproduced by:

  % ld.gold -m elf32ppc -shared /dev/null -o test
  ld.gold: error: /dev/null: file is empty
  ld.gold: internal error in add_output_section_to_load, at gold/output.cc:4097

I have reported this upstream as:

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

Comment 5 Alan Modra 2023-08-25 03:44:45 UTC

Fixed upstream.

Comment 6 Nick Clifton 2023-08-25 14:36:15 UTC

... and in binutils-2.41-5.fc40

Comment 7 Nikita Popov 2023-09-14 14:28:11 UTC

The aforementioned update has shipped, and I confirmed that the LLVM test suite passes again, so marking this as closed.