I spent a little while looking at this problem.

From what I can tell the issue is that our current debug/dwarf reader doesn't support operating on relocatable objects. What this means is that when it goes to read in the contents of things like the .debug_ranges section, it will see a pre-relocation version of the LO/HI PC values, as opposed to the final cooked/relocated value. This is not really so much a bug as it is an implementation shortcoming. The reason that the test works on Darwin is that we are (apparently) emitting fewer relocations.

Some more detail:

I hacked the dwarf.Reader.SeekPC method to print out the contents of the ranges it sees as it tries to locate the compile unit containing the address of interest. When I do this on Linux I see

examining range [0x0,0xdb9]
examining range [0x0,0x5e]
examining range [0x0,0x8a7]
examining range [0x0,0x5980a]
examining range [0x0,0x165]
...

This makes sense, since the .debug_ranges section is in an unrelocated state:

/tmp/go-link-TestDWARF501471370$ objdump -r go.o |  \
  fgrep 'RELOCATION RECORDS' | fgrep .debug
RELOCATION RECORDS FOR [.debug_line]:
RELOCATION RECORDS FOR [.debug_frame]:
RELOCATION RECORDS FOR [.debug_pubnames]:
RELOCATION RECORDS FOR [.debug_pubtypes]:
RELOCATION RECORDS FOR [.debug_info]:
RELOCATION RECORDS FOR [.debug_loc]:
RELOCATION RECORDS FOR [.debug_ranges]:

If I do the same thing on Darwin, here's what I see for relocations:

go-link-TestDWARF386711118 thanm$ gobjdump -r go.o | \
  fgrep 'RELOCATION RECORDS' | fgrep .debug
RELOCATION RECORDS FOR [.debug_line]:
RELOCATION RECORDS FOR [.debug_frame]:
RELOCATION RECORDS FOR [.debug_info]:

Note the lack of .debug_ranges relocations. I think the reason for the discrepancy is https://go-review.googlesource.com/c/go/+/171158, also understandable.

As for what to do about this, I'm unsure at this point (need to consult with other folks).

If the goal of the test is just to verify DWARF generation, then I think perhaps the thing to do would be to do an actual link with the result of the -buildmode=c-archive object, so that the relocations are resolved.

Well now, I stand corrected (having talked this over with Austin). Turns out that debug/elf actually does apply relocations when reading section data to feed into the DWARF reader. So it looks as though the problem may be elsewhere. I will take another look...

I think the culprit is here?

		if SymType(sym.Info&0xf) != STT_SECTION {
			// We don't handle non-section relocations for now.
			continue
		}

Here's the compilation unit DIE as reported by objdump:

 <0><97235>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <97236>   DW_AT_name        : main
    <9723b>   DW_AT_language    : 22	(Go)
    <9723c>   DW_AT_stmt_list   : 0x33790
    <97240>   DW_AT_low_pc      : 0xb80c0
    <97248>   DW_AT_ranges      : 0x490
    <9724c>   DW_AT_comp_dir    : .
    <9724e>   DW_AT_producer    : Go cmd/compile devel +49e7c7672d Mon Sep 16 11:56:15 2019 +0000; -shared
    <97297>   Unknown AT value: 2905: main

The relocations for that section of the .debug_info look like:

000000097230  00020000000a R_X86_64_32       0000000000000000 .debug_abbrev + 0
00000009723c  00030000000a R_X86_64_32       0000000000000000 .debug_line + 33790
000000097240  0fcf00000001 R_X86_64_64       00000000000b80c0 type..eq.[2]interface  + 0
000000097248  00060000000a R_X86_64_32       0000000000000000 .debug_ranges + 490

Note the third relocation -- the symbol this relocation targets is not a section, so that would explain how things are going wrong. So the problem is not that there are no relocations being applied, it's that not quite enough of them are being applied. This doesn't really explain why the test works on Darwin, however (maybe MachO relocations work differently?).

Change https://golang.org/cl/195679 mentions this issue: debug/elf: apply more relocations when reading DWARF data sections