Bug 499164 - gcc or readelf problem
Summary: gcc or readelf problem
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: binutils
Version: 5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Andreas Schwab
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-05 13:59 UTC by Issue Tracker
Modified: 2018-10-27 15:04 UTC (History)
7 users (show)

Fixed In Version: binutils-2.17.50.0.6-13.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 09:04:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Unmushed version of the C code (137 bytes, text/x-csrc)
2009-05-05 14:16 UTC, Kent Baxley
no flags Details
Backport of the upstream fix. (2.41 KB, patch)
2009-07-11 22:53 UTC, Jan Kratochvil
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0304 0 normal SHIPPED_LIVE binutils bug fix update 2010-03-29 14:32:07 UTC

Description Issue Tracker 2009-05-05 13:59:05 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2009-05-05 13:59:07 UTC
Date: Tue, 28 Apr 2009 21:06:49 -0700
Message-Id: <7eff96$1r8ivn.gov>
X-Attachments: None
Received: from auk21.llnl.gov ([134.9.94.176])
  by smtp.llnl.gov with ESMTP; 28 Apr 2009 21:06:48 -0700
From: Matt Wolfe <mwolfe>
To: woodard9
Subject: readelf: Error: Location lists in .debug_info section aren't in ascending order!

Ben,

I ran readelf on a Linux x86-64 g++ 4.2.1-built kull, and ran stdout and
stderr into a single output file.  While browsing the output, in the
middle of the text of the .debug_str section, I found the Subject error
message jammed in at random, which leads me to believe it came from
stderr.

Is this a known problem with g++ 4.2.1 or with the RHEL 5.2 linker?

BTW, I didn't yet confirm whether the details of the .debug_info section
agree with the error message.  I'm assuming it's a true report.

Extra credit: What problems might surface in a debugger as a result of
this condition existing in an executable?

-Matt

Talked to Matt Wolfe on the phone to understand problem more clearly. He found some weird DWARF debuginfo in a program that links two files into an executable. In those files there are two symbols that have the same name, and the same function signature (and come from unrelated pieces of source) but one happens to be a static function internal to the object file and the other is exported.

So when the debugger tries to follow into the function it picks the wrong one. He thinks that maybe the linker might be the problem. It inappropriately merging the DWARF info.

So when the debugger or the linker looks up the symbol to either find it or merge the DWARF into the executable it is finding the wrong one. Thus it is either the DWARF or the interpretation of the DWARF is going awry. 

Matt is working on a reproducer and we'll catch up tomorrow and decide what to do.

Chatted with a guy in the tools team:
<keiths> That is almost certainly (at least) a gdb problem. Ditto duplicate filenames.
<keiths> But a testcase should: 1) be easy to develop; 2) definitively answer the question.
<neb> Yeah I think to make matters even weirder I think that it is duplicate filenames too.
<neb> At least one of the things is a library.



This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 291087

Comment 2 Issue Tracker 2009-05-05 13:59:08 UTC
Date: Mon, 4 May 2009 15:08:54 -0700
Message-Id: <7c0g87$1akt37.gov>
X-Attachments: None
Received: from auk21.llnl.gov ([134.9.94.176])
  by nspiron-2.llnl.gov with ESMTP; 04 May 2009 15:08:54 -0700
From: Matt Wolfe <mwolfe>
To: woodard9
Subject: Re: readelf: Error: Location lists in .debug_info section aren't
in ascending order!

Ben,

Enjoy!

-Matt
------------------------------------------------------------------------
ssh alastor
cat > readelf_error.c << "CAT_INPUT"
void f(int i) {k(i);}

void g(int i) {int j[65537]; l(i,j);}

struct s {void (*m)(int i); void (*n)(int i);} t={f,g};
"CAT_INPUT"
gcc-4.3.2 -g -O -c readelf_error.c
readelf -a -w -W readelf_error.o > readelf_error.o.readelf-a-w-W.stdout
readelf: Error: Location lists in .debug_info section aren't in ascending
order!
readelf: Warning: There is a hole [0x5d - 0x10000] in .debug_loc section.
readelf: Warning: Offset 0x10000 is bigger than .debug_loc section size.
readelf: Warning: There is an overlap [0x10000 - 0x5d] in .debug_loc
section.




This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 291087

Comment 3 Issue Tracker 2009-05-05 13:59:10 UTC
Kent unless you've been living underground, nose buried in a tome of deep
DWARF secrets, you should probably send this one up. I don't think that
either you or I can add much to this.

Can we also get his other question answered.

Problem reproduces on my 5.3 system:

[ben@apbptr tmp]$ gcc43 -g -O0 -c -o test.o test.c 
[ben@apbptr tmp]$ readelf -aw -W test.o >/dev/null
readelf: Warning: There is a hole [0x98 - 0x10000] in .debug_loc section.
readelf: Warning: Offset 0x10000 is bigger than .debug_loc section size.
[ben@apbptr tmp]$ gcc43 -g -O -c -o test.o test.c 
[ben@apbptr tmp]$ readelf -aw -W test.o >/dev/null
readelf: Error: Location lists in .debug_info section aren't in ascending
order!
readelf: Warning: There is a hole [0x5d - 0x10000] in .debug_loc section.
readelf: Warning: Offset 0x10000 is bigger than .debug_loc section size.
readelf: Warning: There is an overlap [0x10000 - 0x5d] in .debug_loc
section.
[ben@apbptr tmp]$ rpm -qf `which gcc43`
gcc43-4.3.2-7.el5
[ben@apbptr tmp]$ rpm -qf `which readelf`
binutils-2.17.50.0.6-9.el5

Note that the problem occurs when move from -O0 to -O

Status set to: Waiting on Tech
Internal Status set to: 'Waiting on Support'

This event sent from IssueTracker by kbaxley  [LLNL (HPC)]
 issue 291087

Comment 4 RHEL Program Management 2009-05-05 14:08:10 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 5 Kent Baxley 2009-05-05 14:16:13 UTC
Created attachment 342468 [details]
Unmushed version of the C code

Comment 6 Jakub Jelinek 2009-05-06 12:55:03 UTC
This is (most likely, I don't see anything wrong on the 4.3 generated code) a RHEL5 readelf bug.
At least F9/F10/F11 readelf dumps it just fine, without errors, while RHEL5/F6/F7/F8 readelf issues errors, on the exact same object file.
The still broken F8 readelf is:
GNU readelf version 2.17.50.0.18-1 20070731
while it works already with:
GNU readelf version 2.18.50.0.6-2 20080403

Comment 8 Issue Tracker 2009-07-01 23:36:57 UTC
Event posted on 2009-07-01 16:36 PDT by woodard

This problem might be related to a problem where ld seems to drop debug
information from a binary that _IS_ in the object files for the object
being linked. The ld problem seems to be associated with this error when
using readelf:

readelf: Error: Range lists in .debug_info section aren't in ascending
order!

However, we have yet to prove that relationship and certainly don't know
the causality of it.


This event sent from IssueTracker by woodard 
 issue 291087

Comment 9 Jan Kratochvil 2009-07-09 19:09:08 UTC
I do not find this problem to be related to Bug 509124.

This problem is only in readelf as Jakub says in Comment #6.  The target binary looks in this Bug perfectly valid to me.

It just needs a backport for RHEL-5.

binutils-2.17.50.0.6-9.el5.x86_64
   12      DW_TAG_subrange_type    [no children]
    DW_AT_type         DW_FORM_ref4
    DW_AT_upper_bound  DW_FORM_data4
 <2><ad>: Abbrev Number: 12 (DW_TAG_subrange_type)
     DW_AT_type        : <b7>
     DW_AT_upper_bound : 0x10000        (location list)
->
binutils-2.19.51.0.2-17.fc11.x86_64
   12      DW_TAG_subrange_type    [no children]
    DW_AT_type         DW_FORM_ref4
    DW_AT_upper_bound  DW_FORM_data4
 <2><ad>: Abbrev Number: 12 (DW_TAG_subrange_type)
    <ae>   DW_AT_type        : <0xb7>
    <b2>   DW_AT_upper_bound : 0x10000

=>
readelf: Error: Location lists in .debug_info section aren't in ascending order!
readelf: Warning: There is a hole [0x5d - 0x10000] in .debug_loc section.
readelf: Warning: Offset 0x10000 is bigger than .debug_loc section size.
readelf: Warning: There is an overlap [0x10000 - 0x5d] in .debug_loc section.

Comment 10 Jan Kratochvil 2009-07-11 22:53:31 UTC
Created attachment 351365 [details]
Backport of the upstream fix.

Upstream check-in by Nick Clifton:
http://sourceware.org/ml/binutils-cvs/2007-11/msg00079.html

New testcase provided as "readelf -wi" - no new test is shown, it is just a part of the existing "readelf -wi" set.

Comment 20 errata-xmlrpc 2010-03-30 09:04:32 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0304.html


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