cmd/link: TestDWARF failing on windows-amd64-longtest #35512
I'm not sure whether this test is even sensible for Windows. It should either be fixed or skipped.
(Either way, that should happen soon so that we can find
The text was updated successfully, but these errors were encountered:
I took a quick look.
Setting aside the question of whether anyone is using c-archive build
I'll send a CL to disable that part of the test for windows for the time
Disable a portion of the TestDWARF testpoint for Windows using c-archive buildmode, pending investigation of the issue at hand, so as to get the longtest builder unblocked. Updates #35512. Change-Id: Ib72d82ceaa674b9a51da220fb8e225231d5c3433 Reviewed-on: https://go-review.googlesource.com/c/go/+/206557 Run-TryBot: Than McIntosh <firstname.lastname@example.org> Reviewed-by: Jeremy Faller <email@example.com>
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
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.