At first glance it looks like a bug. I'm not sure parseAbbrev doesn't handle formIndirect.

It would help if you provide a tiny binary that demonstrates the problem, or instructions for how to create one. Thanks.

Thanks for the reply.

You can trigger the issue using Keil uVision and the "Blinky project Silicon Labs 'EFM32 Giant Gecko microcontroller using Silicon Labs 'EFM32GG-STK3700 Starter Kit' Board", available for installation from Project > Manage > Pack installer. This not to imply the issue is with this particular vendor, I've reproduced it with other projects, too.

Here's the debug file compiled on my machine: Blinky.zip

With the compiled debug version you can run below go code to get error:

elftest.exe efm\Blinky\Debug\Blinky.axf
decoding dwarf section abbrev at offset 0x13: cannot determine class of unknown attribute form

elftest source:

package main

import (
	"debug/elf"
	"fmt"
	"os"
)

func main() {
	if len(os.Args) < 2 {
		fmt.Println("Usage: elftest elf_file")
		os.Exit(1)
	}

	elffile, _ := elf.Open(os.Args[1])

	_, dwarferror := elffile.DWARF()
	if dwarferror != nil {
		fmt.Println(dwarferror.Error())
	}
}

I took a look at this as well. As Ian mentioned the problems seem to relate to the handling of DW_FORM_indirect. There is code in that handles it in the main DIE reader but for some reason it is getting rejected in the abbrev code handler. I will send a tentative fix.

FYI, there is some weird DWARF in the binary you posted. Compile units seem to be getting padded with extra null bytes for some reason. Ex:

 <1><2fa>: Abbrev Number: 80 (DW_TAG_typedef)
    <2fb>   DW_AT_name        : uintmax_t
    <305>   DW_AT_type        : DW_FORM_ref2 <0xed>
    <308>   DW_AT_decl_file   : 1
    <309>   DW_AT_decl_line   : 107
    <30a>   DW_AT_decl_column : 33
 <1><30b>: Abbrev Number: 0
 <0><30c>: Abbrev Number: 0
 <-1><30d>: Abbrev Number: 0
 <-2><30e>: Abbrev Number: 0
 <-3><30f>: Abbrev Number: 0
  Compilation Unit @ offset 0x310:

Note the -2, -3 at the end.

Writing a regression test for this is proving to be tricky -- neither clang nor gcc seem to emit abbrevs that use DW_FORM_indirect. About all I can think of for a test is to check in the Blinky.axf file, which is about 380k. Let me know if there are any ideas for a smaller/better test.

Change https://golang.org/cl/190158 mentions this issue: debug/dwarf: better handling for DW_FORM_indirect

Thanks for the fix! I am out office until beginning of September and won't be able to test until then (best case). For testing in general I cannot make better suggestion either (yet), but I'll add anything else I might come across here later.

@g4w Fix submitted. Let me know if I can close this bug out.

I am going to close this bug, please re-open if you see fit. Thanks.

I managed to do a cursory check and it seems to address my issue, thanks. If something else comes up I'll re-open.

I applied changes fro: https://go-review.googlesource.com/c/go/+/190158/
while using newest go-version golang 1.13.6 amd64 windows version.
But in typeunit.go
I had to change line 140 to (deleted first nil pointer param):
e := tur.b.entry(tur.tu.atable, tur.tu.base, tur.tu.vers)

Now I have dwarf info, but i will check for consistency.