(In particular, I would really like to get the longtest builder passing soon so that we can spot cmd/go regressions on it.)

I took a quick look.

Setting aside the question of whether anyone is using c-archive build
mode on windows, I think the problem seems to be the use of the (relatively)
new SeekPC method in the test code.

I'll send a CL to disable that part of the test for windows for the time
being, and I'll see if I can figure out what the issue is. I do see some
tests in debug/pe that do minimal DWARF checkout, but as far as I can tell
they don't do any line table testing.

Change https://golang.org/cl/206557 mentions this issue: cmd/link: disable a DWARF testpoint on Windows pending investigation

Well, this does look like an actual bug at this point, although I am not really all that sure what the root cause is.

The test is invoking the dwarf reader's SeekPC method, which is running through the ranges associated with each comp unit.

In the (passing non-c-archive) here's what the compilation unit DIE looks like:

 <0><929bf>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <929c0>   DW_AT_name        : main
    <929c5>   DW_AT_language    : 22	(Go)
    <929c6>   DW_AT_stmt_list   : 0x43f33
    <929ca>   DW_AT_low_pc      : 0x4d1ba0
    <929d2>   DW_AT_ranges      : 0x780
    <929d6>   DW_AT_comp_dir    : .
    <929d8>   DW_AT_producer    : Go cmd/compile devel gomote.XXXXX
    <929fa>   Unknown AT value: 2905: main`

and the portion of .debug_ranges pointed to looks like:

   00000780 00000000004d1ba0 00000000004d1c5a 
    00000780 00000000004d23e0 00000000004dc36a

This last range does indeed contain the address of main.main
(0x4d7330), so SeekPC returns the correct unit.

In the c-archive case, here's the compilation unit:

<0><98d46>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <98d47>   DW_AT_name        : main
    <98d4c>   DW_AT_language    : 22	(Go)
    <98d4d>   DW_AT_stmt_list   : 0x43f44
    <98d51>   DW_AT_low_pc      : 0xd0c10
    <98d59>   DW_AT_ranges      : 0x780
    <98d5d>   DW_AT_comp_dir    : .
    <98d5f>   DW_AT_producer    : Go cmd/compile devel gomote.XXXXX
    <98d81>   Unknown AT value: 2905: main

and the corresponding ranges entry looks like:

    00000780 00000000000d0c10 00000000000d0cca 
    00000780 00000000000d1450 00000000000db3da

The test seems to think that the address of main.main in this case is 0x4d63a0 (that's what is being reported by the internal/objfile package), however looking at the output of "objdump -t" I see a value of 0xd63a0. This is also what's being emitted into the DWARF -- here's the subprogram DIE for main.main:

<1><9a4cb>: Abbrev Number: 3 (DW_TAG_subprogram)
    <9a4cc>   DW_AT_name        : main.main
    <9a4d6>   DW_AT_low_pc      : 0xd63a0
    <9a4de>   DW_AT_high_pc     : 0xd659f
    <9a4e6>   DW_AT_frame_base  : 1 byte block: 9c 	(DW_OP_call_frame_cfa)
    <9a4e8>   DW_AT_decl_file   : 0x8
    <9a4ec>   DW_AT_external    : 1

I think this disagreement is the source of the problem.

Also possibly of interest: had to turn off DWARF compression, since it confused the copy of objdump.exe installed on the gomote (test still fails even with -ldflags=-compressdwarf=0).

After taking a closer look, I am not sure whether the linker is actually doing the right thing for c-archive linkage in the first place.

The c-archive build mode is suppose to be generating a relocatable object inside an archive wrapper. However looking at the linker code, it appears to be doing essentially the same thing for c-archive that it does for a regular executable.

At ld/pe.go line 1000 it writes the optional headers for the PE. These headers include things like the image base, which I am pretty sure we don't want to be specifying if we're generating a relocatable object. For example, when you compile some C files into objects (using x86_64 Win64 mingw or equivalent), run "ld -r" on the result, then wrap the result in an archive, you definitely don't get a PE file with the optional headers (which makes sense).

A second concern: in the linux/elf case when you fire up the debug/dwarf reader on a relocatable object, it goes to significant lengths to apply relocations [or at least "enough" of the relocations] to make the DWARF comprehensible. None of this code has been written for PE as far as I can tell, which leads me to believe that having tests that verify the correctness of DWARF for windows/c-archive is a questionable exercise.

I am sure that someone (presumably someone who knows Windows well) could come along and revamp things, e.g. make sure the linker is doing the right thing, and the debug/pe code lays the groundwork for reading DWARF from relocatable PE objects, but until these things are taken care of I don't see much point in running this kind of DWARF test.

With this in mind, I am going to disable the TestDWARF linker testpoint for Windows + c-archive.

Change https://golang.org/cl/206899 mentions this issue: cmd/link: don't run TestDWARF in c-archive mode on Windows