Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ZekeLu opened this issue Sep 21, 2022 · 7 comments
Closed

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

ZekeLu opened this issue Sep 21, 2022 · 7 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.20

Comments

@ZekeLu
Copy link
Contributor

ZekeLu commented Sep 21, 2022

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 script1:
for i in `seq 1 70000`; do
  echo "int var_$i __attribute__((section(\"section_$i\"))) = $i;"
done > y.c
  1. compile y.c:
gcc -c y.c -m32
  1. 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 gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Sep 21, 2022
@ZekeLu ZekeLu mentioned this issue Sep 21, 2022
Closed
@gopherbot
Copy link
Contributor

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

@cherrymui
Copy link
Member

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

@ZekeLu
Copy link
Contributor Author

ZekeLu commented Sep 21, 2022

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 cherrymui added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 21, 2022
@cherrymui cherrymui added this to the Unplanned milestone Sep 21, 2022
@cherrymui
Copy link
Member

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

cc @golang/compiler

@thanm
Copy link
Contributor

thanm commented Sep 21, 2022 •
edited
Loading

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
Copy link
Contributor Author

ZekeLu commented Sep 21, 2022

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
Copy link
Member

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.

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Sep 27, 2022
@dmitshur dmitshur modified the milestones: Unplanned, Go1.20 Sep 27, 2022
@golang golang locked and limited conversation to collaborators Sep 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.20
Development

Successfully merging a pull request may close this issue.

debug/elf: suport files with >= 65280 (0xff00) sections ZekeLu/go
6 participants
@ZekeLu @dmitshur @ianlancetaylor @gopherbot @thanm @cherrymui