debug/elf: files with more than 65280 (0xff00) sections not handled correctly

[ZekeLu]

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zeke/.cache/go-build"
GOENV="/home/zeke/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/zeke/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/zeke/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/snap/go/9951"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/snap/go/9951/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3014639979=/tmp/go-build -gno-record-gcc-switches"

What did you do?

.
├── main.go
├── y.c
└── y.o

1. generate y.c with this script¹:

for i in `seq 1 70000`; do
  echo "int var_$i __attribute__((section(\"section_$i\"))) = $i;"
done > y.c

2. compile y.c:

gcc -c y.c -m32

3. main.go:

package main

import (
	"debug/elf"
	"fmt"
)

func main() {
	f, err := elf.Open("y.o")
	if err != nil {
		panic(err)
	}
	fmt.Println(len(f.Sections))
}

What did you expect to see?

$ go run main.go
70010

$ readelf -h y.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          3338008 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         0 (70010)
  Section header string table index: 65535 (70009)

What did you see instead?

$ go run main.go
0

Footnotes

1. The script is copied from https://sourceware.org/bugzilla/show_bug.cgi?id=5900. Thank you ianlancetaylor@. ↩

[gopherbot]

Change https://go.dev/cl/432255 mentions this issue: debug/elf: suport files with >= 65280 (0xff00) sections

[cherrymui]

Is there a real need for such large number of sections? Or this is just an artificial example? Thanks.

[ZekeLu]

This is just an artificial example. I'm not aware of any object file needs such a large number of sections. The purpose is just to make it compliant with the spec.

[cherrymui]

Thanks. One possible answer is to reject a file with too many sections.

cc @golang/compiler

[thanm]

In my mind it might be worth trying to fix this-- with the right combination of options you can get object files from C compilers that are roughly on that order (without resorting to cooked test cases).

For example, if I go to my LLVM repo, do a build, and find the largest object file in the lib subdir (turns out to be PassBuilder.o), then build that file with "-O0 -ffunction-sections -fdata-section" I get a file with around 35k sections.

$ /usr/bin/clang++-13 ...  -fPIC -fvisibility-inlines-hidden -Werror=date-time ...   -ffunction-sections -fdata-sections -O0 -g    -fno-exceptions -fno-rtti -std=c++14 -c /ssd2/llvm-project/llvm-project/llvm/lib/Passes/PassBuilder.cpp -O0 -o file.o
$ objdump -t file.o | wc
35433  224430 11571920
$

That's less than 65k but it is in the same rough neighborhood.

[ZekeLu]

It seems that you haven't noticed the CL https://go.dev/cl/432255. Please take a look. It is just a small change to fix this.

[ianlancetaylor]

I have seen object files with this many sections in the wild. The ELF spec was changed to support it not just for completeness, but because it was necessary.