Can -headerpad and -pagezero_size be replaced on darwin/arm*?

[Elias Naur]

While investigating the cause of https://golang.org/issue/32963, I found that

the Darwin host linker flag -fembed-bitcode is incompatbile with the flags

-headerpad and -pagezero_size cmd/link passes to host linker. See

    https://github.com/golang/go/issues/32963#issuecomment-539240786

The result is that `gomobile build` fails with a host linker error.

However, building a C archive with -buildmode=c-archive and then using

the host linker to link the archive with a Objective-C main.m does result

in a working binary. That's what you do when using `gomobile bind`.

I've verified by inspection that Xcode does not use -headerpad nor

-pagezero_size when it links an iOS project.

Do you know why the two flags are necessary, and if so, whether it is

possible to replace them?

-- elias

[Than McIntosh]

Hi Elias,

Than McIntosh from the Go team writing. 

I spent a little while looking at the linker sources to understand the history behind these flags.  Not an iOS/MacOS expert, so please bear with me here.

Regarding the introduction of "-no_pie" and "-pagezero_size", the git history is not super helpful there -- in the CLs where they are added there little in the way of explanation as to why they are needed.   I guess m y recommendation would be to try getting rid of them for the IOS/external-linking/exe case that you're interested in.

The -headerpad option was introduced in https://go-review.googlesource.com/c/go/+/10284.  It is needed in order to support the machoCombineDwarf() function (added in the same CL). The header comment for this routine is:

  // machoCombineDwarf merges dwarf info generated by dsymutil into a
  // macho executable. With internal linking, DWARF is embedded into the
  // executable, this lets us do the same for external linking. inexe is
  // the path to the executable with no DWARF. It must have enough room
  // in the macho header to add the DWARF sections. (Use ld's -headerpad
  // option) dsym is the path to the macho file containing DWARF from
  // dsymutil. outexe is the path where the combined executable should
  // be saved.

So this says to me that if we run machoCombineDwarf() to pull the DWARF sections produced by dsymutil back into the main Go object file, -headerpad is required (otherwise the updating would be impossible).

On the other hand, I note that we only invoke machoCombineDwarf() for MacOS, not for iOS, so it should be possible to guard the introduction of the -headerpad flag based on the platform (which is known at the point where we add it).

Does this help I hope? I know a certain amount about LLVM bitcode, but not very much about how bitcode "bundles" and their semantics on Darwin.

Cheers, Than

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/30ddcb78-ceac-4eac-9ae6-c22d7b210df9%40googlegroups.com.

[Elias Naur]

On Tue, Oct 8, 2019 at 10:08 PM Than McIntosh <th...@google.com> wrote:
>
> Hi Elias,
>
> Than McIntosh from the Go team writing.
>
> I spent a little while looking at the linker sources to understand the history behind these flags. Not an iOS/MacOS expert, so please bear with me here.
>
> Regarding the introduction of "-no_pie" and "-pagezero_size", the git history is not super helpful there -- in the CLs where they are added there little in the way of explanation as to why they are needed. I guess m y recommendation would be to try getting rid of them for the IOS/external-linking/exe case that you're interested in.
>
> The -headerpad option was introduced in https://go-review.googlesource.com/c/go/+/10284. It is needed in order to support the machoCombineDwarf() function (added in the same CL). The header comment for this routine is:
>
> // machoCombineDwarf merges dwarf info generated by dsymutil into a
> // macho executable. With internal linking, DWARF is embedded into the
> // executable, this lets us do the same for external linking. inexe is
> // the path to the executable with no DWARF. It must have enough room
> // in the macho header to add the DWARF sections. (Use ld's -headerpad
> // option) dsym is the path to the macho file containing DWARF from
> // dsymutil. outexe is the path where the combined executable should
> // be saved.
>
> So this says to me that if we run machoCombineDwarf() to pull the DWARF sections produced by dsymutil back into the main Go object file, -headerpad is required (otherwise the updating would be impossible).
>
> On the other hand, I note that we only invoke machoCombineDwarf() for MacOS, not for iOS, so it should be possible to guard the introduction of the -headerpad flag based on the platform (which is known at the point where we add it).
>
> Does this help I hope? I know a certain amount about LLVM bitcode, but not very much about how bitcode "bundles" and their semantics on Darwin.
>

Hi Than,

That helped a lot, thank you.

With the new TRY= directive, it was easy to test the hypothesis that
the flags are no longer needed,

https://go-review.googlesource.com/c/go/+/201358

The CL succeeded on darwin/arm64, but failed on darwin/arm:

https://storage.googleapis.com/go-build-log/3550afb2/darwin-arm-mg912baios_df730b83.log

# crypto/aes.test
ld: warning: PIE disabled. Absolute addressing (perhaps
-mdynamic-no-pic) not allowed in code signed PIE, but used in
_runtime.rodata from
/var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/tmp/go-link-786726690/go.o.
To fix this warning, don't compile with -mdynamic-no-pic or link with
-Wl,-no_pie

Do you think it's feasible to avoid absolute addressing in runtime.rodata?

-- elias

[Than McIntosh]

Hi again,

For this error:

>>    # crypto/aes.test    ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in

_runtime.rodata from /var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/tmp/go-link-786726690/go.o.
To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie

I would be happy to look into it, but maybe you could supply a detailed reproducer? It's not clear to me from the trybot log exactly how the code is being built. I assume I can do this on my regular old macbook?

The "runtime.rodata" thing seems odd -- runtime.rodata is a linker generated symbol, but looking at the linker code it appears to just be a pseudo-symbol that incorporates all of the rodata for the program. I ran a couple of regular builds on Darwin/amd64 with -buildmode=pie and looked over the relocations in the Go object file, and I don't see anything suspicious (although I'm not sure if that says much).

Thanks, Than

[Elias Naur]

+ Cherry, who also expressed interest in the darwin/arm problem.

On Wed, Oct 23, 2019 at 9:14 PM Than McIntosh <th...@google.com> wrote:
>
> Hi again,
>
> For this error:
>
> >> # crypto/aes.test ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in
> _runtime.rodata from /var/folders/qq/qxn86k813bn9fjxydm095rxw0000gp/T/workdir-host-darwin-amd64-zenly-ios/tmp/go-link-786726690/go.o.
> To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
>
> I would be happy to look into it, but maybe you could supply a detailed reproducer? It's not clear to me from the trybot log exactly how the code is being built. I assume I can do this on my regular old macbook?
>

Reproduced on my macOS 10.14.6 with Xcode 10.3:

$ GOARCH=arm CGO_ENABLED=1
CC_FOR_TARGET=$(pwd)/../misc/ios/clangwrap.sh ./all.bash
Building Go cmd/dist using /Users/elias/go1.10.1.
Building Go toolchain1 using /Users/elias/go1.10.1.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for host, darwin/amd64.
Building packages and commands for target, darwin/arm.
# cmd/addr2line

ld: warning: PIE disabled. Absolute addressing (perhaps
-mdynamic-no-pic) not allowed in code signed PIE, but used in
_runtime.rodata from

/var/folders/_7/lnt35k555hl2bs7fjygkhgx00000gp/T/go-link-351080933/go.o.

To fix this warning, don't compile with -mdynamic-no-pic or link with
-Wl,-no_pie

# cmd/buildid

ld: warning: PIE disabled. Absolute addressing (perhaps
-mdynamic-no-pic) not allowed in code signed PIE, but used in
_runtime.rodata from

/var/folders/_7/lnt35k555hl2bs7fjygkhgx00000gp/T/go-link-569321767/go.o.

To fix this warning, don't compile with -mdynamic-no-pic or link with
-Wl,-no_pie

# cmd/api

ld: warning: PIE disabled. Absolute addressing (perhaps
-mdynamic-no-pic) not allowed in code signed PIE, but used in
_runtime.rodata from

/var/folders/_7/lnt35k555hl2bs7fjygkhgx00000gp/T/go-link-945236012/go.o.

To fix this warning, don't compile with -mdynamic-no-pic or link with
-Wl,-no_pie

# cmd/cgo
...

-- elias

[Elias Naur]

I forgot to mention I ran the above with CL 201358 and the following
patch applied:

diff --git a/src/cmd/link/internal/ld/lib.go b/src/cmd/link/internal/ld/lib.go
index d5868c9770..78f493ca9f 100644
--- a/src/cmd/link/internal/ld/lib.go
+++ b/src/cmd/link/internal/ld/lib.go
@@ -1206,7 +1206,7 @@ func (ctxt *Link) hostlink() {
switch ctxt.BuildMode {
case BuildModeExe:
if ctxt.HeadType == objabi.Hdarwin {
- if ctxt.Arch.Family != sys.ARM64 {
+ if !ctxt.Arch.InFamily(sys.ARM, sys.ARM64) {
argv = append(argv, "-Wl,-no_pie")
}
if !ctxt.Arch.InFamily(sys.ARM, sys.ARM64) {

-- elias

[Elias Naur]

Moved to https://golang.org/issue/35252.