Does, or Will, Go Support Initialized .data Segments?

182 views
Skip to first unread message

jlfo...@berkeley.edu

unread,
Oct 27, 2021, 1:49:13 PM10/27/21
to golang-nuts
I've noticed that Go doesn't seem to support the intialized .data segment that I used to find on Unix. Is this correct? I've tried using various Go tools to find out but I'm not sure what I was seeing.

If it isn't supported now, is this something planned for the future?

Cordially,
Jon Forrest

Kurtis Rader

unread,
Oct 27, 2021, 2:58:11 PM10/27/21
to jlfo...@berkeley.edu, golang-nuts
On Wed, Oct 27, 2021 at 10:49 AM jlfo...@berkeley.edu <jlfo...@berkeley.edu> wrote:
I've noticed that Go doesn't seem to support the intialized .data segment that I used to find on Unix. Is this correct? I've tried using various Go tools to find out but I'm not sure what I was seeing.

If it isn't supported now, is this something planned for the future?

It's an implementation detail of the architecture. Why do you ask? But to answer your question, yes, Go does populate the data section of the executable. For example, the output of `otool -d` on a Go binary on macOS begins thusly:

elvish:
(__DATA,__data) section
00000000047d7ca0    00 00 00 00 00 00 00 00 b0 b1 40 04 00 00 00 00
00000000047d7cb0    d0 ad 40 04 00 00 00 00 e0 b0 40 04 00 00 00 00
00000000047d7cc0    10 b2 40 04 00 00 00 00 20 e2 50 04 00 00 00 00
00000000047d7cd0    80 e2 7d 04 00 00 00 00 c0 a0 7d 04 00 00 00 00
 
The output of `nm | grep ' [dD] '` of the same program on Linux shows plenty of information in the data section:

0000000000f2d280 D bufio..inittask
0000000000f32720 D bytes.asciiSpace
0000000000f2d2c0 D bytes..inittask
0000000000f1b020 D _cgo_callers

--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

jlfo...@berkeley.edu

unread,
Oct 27, 2021, 6:34:01 PM10/27/21
to golang-nuts
I'm asking because preinitializing an executable binary, where possible, seems like an obvious optimization.
I'm writing baby programs as I'm learning Go, but even they have a significant (to me) number of initializations
that don't need to take up any execution time. On the other hand, modern computers are so fast maybe it's not
even worth paying attention to such things.

I'm not an expert but I don't think the example you showed says anything about preinitialized data. For example,
I built the following trivial program:

package main

var x = []int {1,2,3,4,5,6,7,8}
var s string = "abcdefg"
var p float64 = 3.1415

func main() {
}

and then ran nm on the executable. I didn't see any sign of any of the constants in my program. But,
maybe I don't know what to look for. Your example shows data, but not initialized data. Please
correct me.

Cordially,
Jon Forrest

Ian Lance Taylor

unread,
Oct 27, 2021, 6:54:08 PM10/27/21
to jlfo...@berkeley.edu, golang-nuts
On Wed, Oct 27, 2021 at 3:34 PM jlfo...@berkeley.edu
<jlfo...@berkeley.edu> wrote:
>
> I'm asking because preinitializing an executable binary, where possible, seems like an obvious optimization.
> I'm writing baby programs as I'm learning Go, but even they have a significant (to me) number of initializations
> that don't need to take up any execution time. On the other hand, modern computers are so fast maybe it's not
> even worth paying attention to such things.
>
> I'm not an expert but I don't think the example you showed says anything about preinitialized data. For example,
> I built the following trivial program:
>
> package main
>
> var x = []int {1,2,3,4,5,6,7,8}
> var s string = "abcdefg"
> var p float64 = 3.1415
>
> func main() {
> }
>
> and then ran nm on the executable. I didn't see any sign of any of the constants in my program. But,
> maybe I don't know what to look for. Your example shows data, but not initialized data. Please
> correct me.

The constants won't be in that program because nothing refers to them,
so the compiler will discard them.

Try a program where the constants are actually used. For example,
print them out.

Ian

jlfo...@berkeley.edu

unread,
Oct 27, 2021, 7:14:18 PM10/27/21
to golang-nuts
You're right, of course. Thanks.

So is it true that package level initializations (that are used) require no runtime, other than some loader
time to set up?

Jon

Ian Lance Taylor

unread,
Oct 27, 2021, 10:25:03 PM10/27/21
to jlfo...@berkeley.edu, golang-nuts
On Wed, Oct 27, 2021 at 4:14 PM jlfo...@berkeley.edu
<jlfo...@berkeley.edu> wrote:
>
> So is it true that package level initializations (that are used) require no runtime, other than some loader
> time to set up?

It depends. Go initializers are arbitrarily complex. The compiler
will do them at compile time if possible, but that is not always
possible.

Ian
Reply all
Reply to author
Forward
0 new messages