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/compile: generated DWARF triggers objdump warning for large uint64 const #39048

Open
thanm opened this issue May 13, 2020 · 0 comments
Open

cmd/compile: generated DWARF triggers objdump warning for large uint64 const #39048

thanm opened this issue May 13, 2020 · 0 comments
Assignees

Comments

@thanm
Copy link
Member

@thanm thanm commented May 13, 2020

What version of Go are you using (go version)?

$ go version
go version go1.14.2 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

The Go compiler is emitting DWARF information for certain constants that is causing warnings from 'objdump --dwarf', details below. This is a comparatively minor problem (since as far as I can tell the debugging experience is not impacted) but the warning makes it a pain to read objdump output while looking for other problems (as a Go developer, not a Go user).

Code:

package main

import "fmt"

const neg64 uint64 = 1 << 63

func main() {
	fmt.Println(neg64)
}

Symptoms:

$ go build neg64.go
$ objdump --dwarf=info neg64 >  /dev/null
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large
objdump: Error: LEB value too large

What did you expect to see?

clean objdump output with no warnings

What did you see instead?

LEB value too large warnings.

DWARF output excerpt:

 <1><79f2b>: Abbrev Number: 9 (DW_TAG_constant)
    <79f2c>   DW_AT_name        : main.neg64
    <79f37>   DW_AT_type        : <0x3bf51>
    <79f3b>   DW_AT_const_value :objdump: Error: LEB value too large
 -9223372036854775808

where the type in question is listed as

 <1><3bf51>: Abbrev Number: 27 (DW_TAG_base_type)
    <3bf52>   DW_AT_name        : uint64
    <3bf59>   DW_AT_encoding    : 7	(unsigned)
    <3bf5a>   DW_AT_byte_size   : 8
    <3bf5b>   Unknown AT value: 2900: 11
    <3bf5c>   Unknown AT value: 2904: 0xdec0

I think what's happening here is that the abbrev entry looks like this:

    DW_TAG_constant    [no children]
    DW_AT_name         DW_FORM_string
    DW_AT_type         DW_FORM_ref_addr
    DW_AT_const_value  DW_FORM_sdata
    DW_AT value: 0     DW_FORM value: 0

Note the DW_FORM_sdata payload -- this is a signed value. I am assuming that objdump is interpreting this combination as something along the lines of "take this signed value and put it into an 8-byte signed container" (at which point it decides it can't fit).

A possible workaround would be to use a different abbrev with FORM_udata instead.

It's also arguable that we should instead file a binutils bug and ask them to change the objdump behavior -- you can make case that the Go DWARF is ok and it should be getting the "signedness" from the destination type and not the form (just depends on how you interpret things).

@thanm thanm self-assigned this May 13, 2020
@odeke-em odeke-em changed the title DWARF from go compiler triggers objdump warning for large uint64 const cmd/compile: generated DWARF triggers objdump warning for large uint64 const May 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.