From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32067 invoked by alias); 12 Jan 2010 08:55:45 -0000 Received: (qmail 32043 invoked by uid 22791); 12 Jan 2010 08:55:45 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jan 2010 08:55:41 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 2C965CB0259; Tue, 12 Jan 2010 09:55:39 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwFJ6CVNxeHO; Tue, 12 Jan 2010 09:55:39 +0100 (CET) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 17132CB016C; Tue, 12 Jan 2010 09:55:39 +0100 (CET) Subject: Re: [RFA] Fix has_section_at_zero for separate debug files Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Tristan Gingold In-Reply-To: Date: Tue, 12 Jan 2010 08:55:00 -0000 Cc: Tristan Gingold , gdb-patches@sourceware.org, kevinb@redhat.com Content-Transfer-Encoding: quoted-printable Message-Id: <3250D752-12F1-4FE9-ADFF-E046B4DCF7DE@adacore.com> References: <20100107130918.GA11037@chinon.act-europe.fr> To: tromey@redhat.com 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-01/txt/msg00294.txt.bz2 On Jan 11, 2010, at 10:28 PM, Tom Tromey wrote: >>>>>> "Tristan" =3D=3D Tristan Gingold writes: >=20 > Tristan> this patch reconsiders the approach taken in > Tristan> http://sourceware.org/ml/gdb-patches/2009-06/msg00116.html >=20 > Tristan> The new problem is that has_section_at_zero is now wrongly > Tristan> cleared. This happens when the separate debug file is a > Tristan> relocatable file (such as on Darwin) which may have a function > Tristan> at address 0. If its backlink (ie the executable) has no > Tristan> section at 0 (which is the rule), one or more symbols disappear > Tristan> in the symtab. >=20 > This seems strange to me. My mental model is that the separate debug > objfile describes the parent objfile. That's correct. > To me this implies that on Darwin > you ought to relocate the separate debug objects. Currently we don't relocate it (ie we don't apply relocs), we simply set of= fsets. But the code doesn't tests offsets. Of course not relocating is somewhat wrong, because of common symbols. But= that's how it works now, and I am working on using relocations. > Tristan> Because a separate debug file may be completely unrelated (in > Tristan> terms of mapping) from its backlink, we shouldn't try to copy > Tristan> the has_section_at_zero. Instead, we also consider SEC_ALLOC > Tristan> sections to set has_section_at_zero. This makes sense because > Tristan> you may perfectly have the bss at zero. >=20 > This also seems a little weird, given that has_section_at_zero is only > used to determine whether PC ranges are valid in some situations. Argh, you're right. I thought it was also used to check wether variables e= xists or not. > Tristan> No regression on GNU Linux i386. >=20 > I wonder whether this code path is tested there. > I don't know. I think so. I tested the little example with gdb unpatched, with the code = removed in the patch (failure) and with the full patch. Tristan.