Commit 8364f54
committed
Revert ineffective "drop DWARF from Windows Go test binary links"
This reverts commit 078d86b (#54903).
### Motivation
`-w` was measured inert against the failure it was meant to mitigate.
The OOM is in Go's own linker, not mingw `ld`: all 25 `errno=1455` dumps
in job 1951788199 sit in `loadlib` -> `LoadSyms` -> `preloadSyms`.
`-w` suppresses `DwarfGenerateDebugSyms`, which runs after `loadlib`,
and it does not shrink the linker input either, because the compiler
emits DWARF into the object files regardless (`-dwarf` defaults to
true).
### Describe how you validated your changes
Windows VM, 20 GB commit ceiling, `GOMEMLIMIT=2560MiB`, 3 reps each of:
```
go test -p 8 -race -cover -covermode=atomic ./cmd/...
```
```
without -w 2/3 OOM peaks 16,581-17,299 MB
with -w 2/3 OOM peaks 16,768-17,240 MB
```
Per-phase linker heap on Linux, `-ldflags=-benchmark=mem`, `-race`:
```
Loadlib live DwarfGenerateDebugSyms alloc
baseline 420.2 MB 412.9 MB
-w 420.5 MB 0
```
`Loadlib` is unchanged to within 0.3 MB, which is why the OOM rate does
not move.
### Additional Notes
`-w` does cut peak link heap by 19 percent on Linux, 637 MB to 518 MB,
and costs no diagnostics because `pclntab` is untouched.
That saving is real but sits on the **wrong side of the failing phase**.
Capping build concurrency is what addresses the OOM: `-p 5` was 0/8
clean where `-p 8` was 3/3 OOM.
Measured on a 20 GB bare host over `./cmd/...` without the `python` tag,
so the ordering transfers but the absolute numbers are not CI's.1 parent 3067dd1 commit 8364f54
1 file changed
Lines changed: 0 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
667 | 667 | | |
668 | 668 | | |
669 | 669 | | |
670 | | - | |
671 | | - | |
672 | | - | |
673 | 670 | | |
674 | 671 | | |
675 | 672 | | |
| |||
0 commit comments