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