Escalated to Bugzilla from IssueTracker
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
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
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
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 "?".
Created attachment 342468 [details] Unmushed version of the C code
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
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
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.
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.
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