From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14766 invoked by alias); 24 Mar 2010 20:09:54 -0000 Received: (qmail 14757 invoked by uid 22791); 24 Mar 2010 20:09:53 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Mar 2010 20:09:48 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2OK9lJd032720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Mar 2010 16:09:47 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2OK9i1v031170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 16:09:46 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id o2OK9iwv014090; Wed, 24 Mar 2010 21:09:44 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id o2OK9hkE014089; Wed, 24 Mar 2010 21:09:43 +0100 Date: Wed, 24 Mar 2010 20:09:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix separate-debug with non-unique section names (PR 11409) Message-ID: <20100324200943.GA12225@host0.dyn.jankratochvil.net> References: <20100323205655.GA12124@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-03/txt/msg00816.txt.bz2 On Wed, 24 Mar 2010 20:02:07 +0100, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > > Jan> gdb-7.1 is now broken for example for debugging /usr/bin/emacs due to: > Jan> http://sourceware.org/bugzilla/show_bug.cgi?id=11409 > Jan> [22] .data PROGBITS 00000000007fe8a0 1fe8a0 215068 00 WA 0 0 32 > Jan> [23] .data PROGBITS 0000000000a13920 413920 68c6e0 00 WA 0 0 32 > > Jan> 2010-03-23 Jan Kratochvil > Jan> * symfile.c (addr_info_make_relative): Move sect declaration to the > Jan> outer block. Initialize it to NULL. Prefer SECT->next more than > Jan> bfd_get_section_by_name. > > This patch seems to assume that all sections of the same name will be > next to each other in the section_addr_info. Why is it ok to make this > assumption? The code generally assumes the sections in .debug file are in the same order as in the main file. Only if there is some discrepancy it will resync by bfd_get_section_by_name. The resync should not normally happen. Attached an illustrative /bin/bash -> /usr/lib/debug/bin/bash.debug section diff. The only resynchronizations happen there on system part of sections - and these have unique name. The problem is I do not know how to match sections main<->.debug file when their name is not unique. One could check VMAs but - to find the difference of VMAs is the goal of this function. Assuming for executables + shared libraries there are never many sections there. This emacs .data section duplicity is more an exception. The only cases with many (thousands of) sections I am aware of are object files but object files should get into addr_info_make_relative at all (I hope the Mach-O support does not use it for the .o symbols loading). ld --split-by-file=1 creates section names like .text.0 ... .text.1454 all unique; by bfd_get_unique_section_name. While the algorithm could be much more clever - if we ever need to resync at the point of non-unique section names the files are too different it makes no sence to try to match them by addr_info_make_relative at all. I may have forgot about this case, not sure, but I do not find it a problem. Thanks, Jan ------------------- .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym -.gnu.liblist -.gnu.conflict +.dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .ctors .dtors .jcr .dynamic .got .got.plt .data -.dynbss .bss -.dynstr -.gnu_debuglink -.gnu.prelink_undo +.comment +.debug_aranges +.debug_pubnames +.debug_info +.debug_abbrev +.debug_line +.debug_str +.debug_loc +.debug_pubtypes +.debug_ranges .shstrtab +.symtab +.strtab