Skip to content
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.

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

cmd/link: Any plan to support to link libhugetlbfs on the Golang linker? #50549

Closed
hailingluo opened this issue Jan 11, 2022 · 6 comments
Closed
Labels
Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@hailingluo
Copy link

hailingluo commented Jan 11, 2022

Hi, everyone
I'm researching how to use the golang linker to link libhugetlbfs. And I find the C dynamic library cannot be directly linked except using cgo or directly using external linker (such as ld/gold/lld). I have two question as follows:

  1. Is there any plan to support to link libhugetlbfs on the Golang linker?
  2. If not, I think it should be supported. Because ld, gold, and lld are all supported, and golang linker as a modern linker should be able to linker the C dynamic libraries. And if we want to support it, how difficult is it?
@cherrymui
Copy link
Member

cherrymui commented Jan 11, 2022

I'm not sure I understand this. Could you explain what you'd like to do, like, what commands you'd want to run which is not currently available? What do you mean by "directly linked"?

If I understand correctly, libhugetlbfs is a C library, so cgo needs to be involved to use it.

Thanks.

@cherrymui cherrymui added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jan 11, 2022
@hailingluo
Copy link
Author

hailingluo commented Jan 12, 2022

Yes, libhugetlbfs is a C library. If we use cgo to link this library, maybe only C code is mapped to hugepage. The external linker (such as ld or gold) can linker go.o, libhugetlbfs.so and the other libraries, then both Go code and C can be mapped to hugepage. While our goal is to make both the go code and c code use hugepages by the internal linker (Golang linker).

Using the external linker: libhugetlb.so is linked.

Using the internal linker:
We have no commands to append the libhugetlbfs.so to the final binary.

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Jan 12, 2022

The Go runtime on Linux makes direct system calls. It does not use the C library. Linking against libhugetlbfs will not affect Go code. It will only affect C code. So I don't think there is anything to do here.

@hailingluo
Copy link
Author

hailingluo commented Jan 17, 2022

The Go runtime on Linux makes direct system calls. It does not use the C library. Linking against libhugetlbfs will not affect Go code. It will only affect C code. So I don't think there is anything to do here.

Sorry for the late reply. I use the command "go build -a -ldflags='-extld=gcc "-extldflags=-zcommon-page-size=2097152 -zmax-page-size=2097152 -L/usr/lib64 -lhugetlbfs -fuse-ld=bfd" -linkmode=external -buildid=IdNone' demo.go", then run ./demo (demo.go are written by only go)

We found that this go code is affect by C library (libhugetlbfs.so)

@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Jan 17, 2022

When you build a Go program with -linkmode=external, then the Go program is linked with the C library. In that case the C library code will be using huge pages. But it is still true that the Go code itself will not be affected by libhugetlbfs.

@cherrymui
Copy link
Member

cherrymui commented Jan 18, 2022

As @ianlancetaylor said. I don't think we want to link with a C library for pure Go programs. If we want the text segment to be backed by hugepages, we should probably use some other mechanism instead of a C library. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

3 participants