Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056797 - bfd/dwarf2.c doesn't handle DW_FORM_ref_addr and DW_FORM_GNU_ref_alt correctly
Summary: bfd/dwarf2.c doesn't handle DW_FORM_ref_addr and DW_FORM_GNU_ref_alt correctly
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-22 23:06 UTC by Andy Lutomirski
Modified: 2015-06-01 08:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-01 08:11:31 UTC


Attachments (Terms of Use)

Description Andy Lutomirski 2014-01-22 23:06:15 UTC
dwz take perfectly fine .so files and generates output that causes addr2line to blow up.  I don't know whether this is a dwz bug or a binutils bug.

I'm filing this here because sourceware's bugzilla appears to be mostly useless and because all of this stuff is now in Fedora.

Upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15204

Comment 1 Jakub Jelinek 2014-01-22 23:20:55 UTC
Can't reproduce on the binaries and shared libraries I've tried.  Can you attach the shared library you have problems with (before running dwz on it) and the address you're trying to look up?
Does eu-addr2line work?

Comment 2 Mark Wielaard 2014-01-22 23:22:24 UTC
I think it is an binutils bug not a dwz one. When I try the example from the upstream bug with elfutils eu-addr2line it seems to work fine.

    eu-addr2line -e orig.so 0x00000000000247b8
    src/central_freelist.cc:283

    eu-addr2line -e dwz.so 0x00000000000247b8
    src/central_freelist.cc:283

Comment 3 Mark Wielaard 2014-01-22 23:24:54 UTC
BTW. The example files are here:
http://web.mit.edu/luto/www/binutils_bug/

And indeed with GNU addr2line version 2.23.2
$ addr2line -e dwz.so 0x00000000000247b8
BFD: Dwarf Error: Could not find abbrev number 91.
BFD: Dwarf Error: Could not find abbrev number 111.
BFD: Dwarf Error: Could not find abbrev number 91.
BFD: Dwarf Error: Offset (7632208) greater than or equal to .debug_str size (281777).
BFD: Dwarf Error: Could not find abbrev number 101.
BFD: Dwarf Error: Could not find abbrev number 113.
/home/luto/apps/gperftools/src/central_freelist.cc:283

Comment 4 Andy Lutomirski 2014-01-22 23:52:17 UTC
I am definitely not qualified to tell whether dwz is generating bogus data that eu-addr2line doesn't care about or whether binutils is messed up.  If you think it's more likely to be binutils' fault, please reassign this bug.

Comment 5 Jakub Jelinek 2014-01-23 08:36:03 UTC
Indeed, it is a binutils bug.
For the first error, we have:
  Compilation Unit @ offset 0x204f:
   Length:        0x2c (32-bit)
   Version:       4
   Abbrev Offset: 0x6e3
   Pointer Size:  8
 <0><205a>: Abbrev Number: 4 (DW_TAG_partial_unit)
    <205b>   DW_AT_stmt_list   : 0x0    
    <205f>   DW_AT_comp_dir    : (indirect string, offset: 0x955c): /home/luto/apps/gperftools  
 <1><2063>: Abbrev Number: 11 (DW_TAG_subprogram)
    <2064>   DW_AT_specification: <0x1fa9>      
    <2068>   DW_AT_inline      : 3      (declared as inline and inlined)
    <2069>   DW_AT_object_pointer: <0x206a>     
 <2><206a>: Abbrev Number: 13 (DW_TAG_formal_parameter)
    <206b>   DW_AT_name        : (indirect string, offset: 0x33a4): this        
    <206f>   DW_AT_type        : <0x204b>       
    <2073>   DW_AT_artificial  : 1      
 <2><2073>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <2074>   DW_AT_name        : cl     
    <2077>   DW_AT_decl_file   : 6      
    <2078>   DW_AT_decl_line   : 227    
    <2079>   DW_AT_type        : <0x7d> 
 <2><207d>: Abbrev Number: 0
 <1><207e>: Abbrev Number: 0
and the form for DW_AT_specification is DW_FORM_ref_addr.  Abbrevs at offset 0x6e3 indeed don't define abbrev number 91, but that is not used in this CU.
0x1fa9 is in a different CU though:
  Compilation Unit @ offset 0x1ecc:
   Length:        0x17f (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
...
 <3><1fa9>: Abbrev Number: 91 (DW_TAG_subprogram)
    <1faa>   DW_AT_external    : 1      
    <1faa>   DW_AT_name        : (indirect string, offset: 0x3e07): ByteSizeForClass    
    <1fae>   DW_AT_decl_file   : 6      
    <1faf>   DW_AT_decl_line   : 227    
    <1fb0>   DW_AT_linkage_name: (indirect string, offset: 0x155f): _ZN8tcmalloc7SizeMap16ByteSizeForClassEm    
    <1fb4>   DW_AT_type        : <0x7d> 
    <1fb8>   DW_AT_accessibility: 1     (public)
    <1fb9>   DW_AT_declaration : 1      
    <1fb9>   DW_AT_object_pointer: <0x1fbd>     
    <1fbb>   DW_AT_sibling     : <0x1fc6>       
and uses abbrev number 91, but as it is a reference to a DIE in a different CU, dwarf2.c should have used different abbreviation table.
So, I think the bug is in find_abstract_instance_name, for DW_FORM_ref_addr and DW_FORM_GNU_ref_alt it is wrong to use blindly unit->abbrevs.
For the first form, it needs to find corresponding CU containing it (either linearly walking the list of all CUs and see if it falls into the range, or e.g. having an array of starting
offsets of the CUs (and corresponding pointer to the unit) and do a binary search, then verify it falls into the range of the discovered CU and if so, use that unit's abbrevs instead of current unit's.  For DW_FORM_GNU_ref_alt, it would need similarly not just load the alternate unit's section, but parse the CUs quickly to find offsets and abbrev units.

Comment 6 Nick Clifton 2014-01-28 11:46:15 UTC
binutils-2.23.88.0.1-16.fc20 now contains a patch based on the suggestion made by Jakub.  This only updates the handling of the DW_FORM_ref_alt attribute, but this appears to be enough for the test cases provided.

I suspect that the code to handle the DW_FORM_GNU_ref_alt attribute may also need updating, but I need a testcase for that first.

Cheers
  Nick

Comment 7 Andy Lutomirski 2014-01-28 20:12:49 UTC
I haven't tested the new Fedora build, but binutils trunk now survives a pprof run with no obvious problems.  Thanks!

(Note: Fedora's binutils has a worse bug.  I'll file a separate ticket.)

Comment 8 Fedora End Of Life 2015-05-29 10:37:44 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 9 Mark Wielaard 2015-06-01 08:11:31 UTC
According to comment #7 this was fixed (at least upstream).


Note You need to log in before you can comment on or make changes to this bug.