Segment Header Table defines `.note.go.buildid` loaded, why?

[Zhang Jie (Kn)]

From the output of `readelf -l <app>` , we can see `.note.go.buildid` and `.text` sections are both loaded.

I want to know why `.note.go.buildid` is loaded, it seems go source code doesn't read it at all.

I read the discussion here: https://github.com/golang/go/issues/68652. Looks like gobuildid should be used only in go build tools. I searched and only `go tool pprof` uses the `buildid`, but it is the GNU buildID rather than go buildID

ps:  `ParseMemoryMap -> elfBuildID`, `elfBuildID` only read the GNU buildID.

[Elrefaei Mohammed]

Why doesn't read it at all I need to discussion all tools

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2f0a65a1-49d0-4e69-b6ea-ca3bb437171an%40googlegroups.com.

[Zhang Jie (Kn)]

I see this issue: https://github.com/golang/go/issues/19431

In the mentioned PR, Russ add the code to parse /proc/<pid>/maps to get the executable filename, and then read it to parse the section to get the GNU build id, rather than the go build id, .... see the function: func elfBuildID(file string) (string, error)

It will record the GNU build id in the generated pprof profile.

- go build , the linker will create segments like this: 

    01 .note.go.builid

    02     .text .note.go.buildid

- go build -ldflags "-B gobuilid", the linker will create segment like this: 

   01 .note.go.builid   

   02     .text .note.gnu.build-id .note.go.buildid

So far, I think there's no any go internal tools read them directly, to get the GNU build id and go build id are achieved by parse the ELF sections.

---

So why does the linker create segment like these to load the .note.go.build and .note.gnu.build-id? To generate the core or memory dump to include the GNU build id and the go build id?

But if we can't get the matched executable, we can't get the ELF sections and segments info, we don't know the loaded address, we still cannot parse the memory dump area to get the right build id value.

Please help.