From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29125 invoked by alias); 25 Jul 2012 18:54:29 -0000 Received: (qmail 29110 invoked by uid 22791); 25 Jul 2012 18:54:28 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,TW_BJ,TW_CP,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 18:54:15 +0000 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Jul 2012 14:54:14 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Jul 2012 14:53:20 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 29BD56E816D for ; Wed, 25 Jul 2012 14:47:28 -0400 (EDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6PIlQjE427732 for ; Wed, 25 Jul 2012 14:47:26 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6PIlLZe013187 for ; Wed, 25 Jul 2012 12:47:21 -0600 Received: from [9.47.28.73] ([9.47.28.73]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q6PIlLHc013151; Wed, 25 Jul 2012 12:47:21 -0600 Subject: bt: order of .text symbols in debuginfo important? From: Jim Keniston To: gdb@sourceware.org Cc: Jim Keniston Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 Jul 2012 18:54:00 -0000 Message-ID: <1343242040.3415.43.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072518-5806-0000-0000-000017A9C9FE Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00077.txt.bz2 For purposes of associating functions with .text addresses when creating a backtrace, does gdb assume that the .text symbols for static functions in a particular source file are in ascending order by address in the debuginfo file? That seems to be the case ALMOST universally in the debuginfo file I'm looking at, but there's one source file (ehandler.c) with just 2 static functions, and they're in reverse order in the debuginfo: $ objdump -t fsck.ext2.debug ... 0000000000000000 l df *ABS* 0000000000000000 ehandler.c 000000000062d340 l O .bss 0000000000000008 operation 000000000041a540 l F .text 00000000000001bc e2fsck_handle_read_error 000000000041a3d0 l F .text 000000000000016f e2fsck_handle_write_error 0000000000000000 l df *ABS* 0000000000000000 problem.c 000000000062cd40 l O .data 00000000000000b0 pr_latch_info 000000000041a7d0 l F .text 000000000000005d reconfigure_bool ... This is of interest to me because gdb's bt of a core file goes bad when it hits e2fsck_handle_read_error's frame: ... Loaded symbols for /lib64/ld-linux-x86-64.so.2 Core was generated by `fsck.ext2 -f -y /dev/buse0'. Program terminated with signal 11, Segmentation fault. #0 0x00007f1618b0db8b in memcpy () from /lib64/libc.so.6 (gdb) where #0 0x00007f1618b0db8b in memcpy () from /lib64/libc.so.6 #1 0x00007f1619633473 in reuse_cache (block=, cache=, data=, channel=) at /usr/include/bits/string3.h:52 #2 unix_write_blk64 (block=, cache=, data=, channel=) at unix_io.c:690 #3 0x000000000041a6c1 in ?? () #4 0x00007fff430432c0 in ?? () #5 0x000000007f2bb724 in ?? () #6 0x0000000000000000 in ?? () (gdb) For comparison, when I point a fresh gdb instance at fsck.ext2 (no core file), I'm able to set a breakpoint at e2fsck_handle_read_error. Thanks for any suggestions. I'd appreciate being cc-ed on responses, since I'm not subscribed to this list; but I'll monitor the archive for a while just in case. Jim Keniston IBM Linux Technology Center