debug/dwarf: invalid string values due to incorrect strp offsets

[4a6f656c]

cgo on OpenBSD/amd64 is currently unable to generate correct z-files, due to what
appears to be a bug in our debug/dwarf package. Attached is a minimal types_openbsd.go
file and the corresponding .o file that gcc creates. The sample dwarf.go should produce
the following output for struct timeval:

  Name: timeval
  Name: tv_sec
  Name: tv_usec

However, it currently produces:

  Name: timeval
  Name: it_interval
  Name: tv_usec

Due to duplication tv_sec is encoded as a strp, however debug/dwarf ends up determining
that it has an offset of 0x0 instead of the correct 0xc, which obviously results in the
incorrect value.

It is possible that this is compiler related, however I doubt that this is the case
since readelf is able to correctly process the .o file on multiple platforms (in this
case linux/amd64):

$ readelf --debug-dump _cgo_.o | grep -A 10 :\ timeval
    <b80>   DW_AT_name        : timeval   
    <b88>   DW_AT_byte_size   : 16    
    <b89>   DW_AT_decl_file   : 6 
    <b8a>   DW_AT_decl_line   : 90    
    <b8b>   DW_AT_sibling     : <0xbb0> 
 <2><b8f>: Abbrev Number: 14 (DW_TAG_member)
    <b90>   DW_AT_name        : (indirect string, offset: 0xc): tv_sec    
    <b94>   DW_AT_decl_file   : 7 
    <b95>   DW_AT_decl_line   : 50    
    <b96>   DW_AT_type        : <0x361> 
    <b9a>   DW_AT_data_member_location: 2 byte block: 23 0    (DW_OP_plus_uconst: 0)

Attachments:

1. types_openbsd.go (392 bytes)
2. dwarf.go (476 bytes)
3. cgo.o (6544 bytes)

[rsc]

Comment 1:

Labels changed: added go1.1.

[4a6f656c]

Comment 2:

So it turns out that this due to a well hidden bug in debug/elf - the object in question
contains a rela.debug_info section, which contains the offsets into the string table.
However, the relocation for the given section is not processed, resulting in all strp
offsets referring to the first entry in the string table.
The root cause is an off-by-one error caused by debug/elf discarding the first symbol in
the symbol table. As a result, the relocation code actually checks the following symbol
and if it does not have a type of STT_SECTION then the relocation is skipped.
Unfortunately, all of the objects used for the existing relocation tests have symbols of
type STT_SECTION that follow the symbol that requires relocation, hence they relocate
correctly.
There are two obvious fixes - stop skipping over the first symbol in the symbol table or
adjust the index when performing relocation. I suspect the first of these is more
"correct" since any data that contains an index into the symbol table will potentially
encounter the same issue. Furthermore, code that uses debug/elf or debug/dwarf should
not need to know that they must adjust for this.

Owner changed to @4a6f656c.

[mikioh]

Comment 3:

Issue #4378 has been merged into this issue.

[4a6f656c]

Comment 4:

This issue was closed by revision 7668984.

Status changed to Fixed.