Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: TestDWARF failing on windows-amd64-longtest #35512

Closed
bcmills opened this issue Nov 11, 2019 · 6 comments
Closed

cmd/link: TestDWARF failing on windows-amd64-longtest #35512

bcmills opened this issue Nov 11, 2019 · 6 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Nov 11, 2019

From the windows-amd64-longtest builder (https://build.golang.org/log/ff007246c760fef4ec1565e85eb7c578204bdec0):

--- FAIL: TestDWARF (14.21s)
    --- FAIL: TestDWARF/c-archive (0.24s)
        --- FAIL: TestDWARF/c-archive/testprog (1.03s)
            dwarf_test.go:149: ErrUnknownPC
        --- FAIL: TestDWARF/c-archive/testprogcgo (13.73s)
            dwarf_test.go:149: ErrUnknownPC

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 longtest failures in other packages.)

CC @cherrymui @thanm @jeremyfaller @zx2c4 @alexbrainman

@bcmills

This comment has been minimized.

Copy link
Member Author

@bcmills bcmills commented Nov 11, 2019

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

@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 11, 2019

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.

@thanm thanm self-assigned this Nov 11, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 11, 2019

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

gopherbot pushed a commit that referenced this issue Nov 11, 2019
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 <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 12, 2019

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).

@bcmills bcmills removed the Soon label Nov 12, 2019
@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 13, 2019

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.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Nov 13, 2019

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

@gopherbot gopherbot closed this in 62581ee Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.