cmd: fix DWARF gen bug with packages that use assembly

When the compiler builds a Go package with DWARF 5 generation enabled,
it emits relocations into various generated DWARF symbols (ex:
SDWARFFCN) that use the R_DWTXTADDR_* flavor of relocations. The
specific size of this relocation is selected based on the total number
of functions in the package -- if the package is tiny (just a couple
funcs) we can use R_DWTXTADDR_U1 relocs (which target just a byte); if
the package is larger we might need to use the 2-byte or 3-byte flavor
of this reloc.

Prior to this patch, the strategy used to pick the right relocation
size was flawed in that it didn't take into account packages with
assembly code. For example, if you have a package P with 200 funcs
written in Go source and 200 funcs written in assembly, you can't use
the R_DWTXTADDR_U1 reloc flavor for indirect text references since the
real function count for the package (asm + go) exceeds 255.

The new strategy (with this patch) is to have the compiler look at the
"symabis" file to determine the count of assembly functions. For the
assembler, rather than create additional plumbing to pass in the Go
source func count we just use an dummy (artificially high) function
count so as to select a relocation that will be large enough.

Fixes #72810.
Updates #26379.

Change-Id: I98d04f3c6aacca1dafe1f1610c99c77db290d1d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/663235
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>

src/cmd/asm/main.go

@@ -49,6 +49,7 @@ func main() {
 	ctxt.Debugpcln = flags.DebugFlags.PCTab
 	ctxt.IsAsm = true
 	ctxt.Pkgpath = *flags.Importpath
+	ctxt.DwTextCount = objabi.DummyDwarfFunctionCountForAssembler()
 	switch *flags.Spectre {
 	default:
 		log.Printf("unknown setting -spectre=%s", *flags.Spectre)

src/cmd/compile/internal/ssagen/abi.go

@@ -89,6 +89,7 @@ func (s *SymABIs) ReadSymABIs(file string) {
 			// Record for later.
 			if parts[0] == "def" {
 				s.defs[sym] = abi
+				base.Ctxt.DwTextCount++
 			} else {
 				s.refs[sym] |= obj.ABISetOf(abi)
 			}

src/cmd/internal/objabi/reloctype.go

@@ -482,6 +482,30 @@ func FuncCountToDwTxtAddrFlavor(fncount int) (RelocType, int) {
 	}
 }
 
+// DummyDwarfFunctionCountForAssembler returns a dummy value to be
+// used for "total number of functions in the package" for use in the
+// assembler (compiler does not call this function).
+//
+// Background/motivation: let's say we have a package P with some
+// assembly functions (in "a.s") and some Go functions (in
+// "b.go"). The compilation sequence used by the Go commmand will be:
+//
+// 1. run the assembler on a.s to generate a "symabis" file
+// 2. run the compiler on b.go passing it the symabis file and generating a "go_defs.h" asm header
+// 3. run the assembler on a.s passing it an include dir with the generated "go_defs.h" file
+//
+// When the compiler runs, it can easily determine the total function
+// count for the package (for use with FuncCountToDwTxtAddrFlavor
+// above) by counting defined Go funcs and looking at the symabis
+// file. With the assembler however there is no easy way for it to
+// figure out the total number of Go source funcs. To keep things
+// simple, we instead just use a dummy total function count while
+// running the assembler that will guarantee we pick a relocation
+// flavor that will work for any package size.
+func DummyDwarfFunctionCountForAssembler() int {
+	return 9999999
+}
+
 // DwTxtAddrRelocParams returns the maximum number of functions per
 // package supported for the DWARF .debug_addr relocation variant r,
 // along with the number of bytes it takes up in encoded form.