From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27487 invoked by alias); 10 Jun 2015 08:54:07 -0000 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 Received: (qmail 27477 invoked by uid 89); 10 Jun 2015 08:54:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 10 Jun 2015 08:54:05 +0000 Received: by payr10 with SMTP id r10so30841851pay.1 for ; Wed, 10 Jun 2015 01:54:03 -0700 (PDT) X-Received: by 10.70.41.135 with SMTP id f7mr3813828pdl.113.1433926443519; Wed, 10 Jun 2015 01:54:03 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id zt9sm7913995pac.9.2015.06.10.01.54.01 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 10 Jun 2015 01:54:02 -0700 (PDT) From: Yao Qi To: Taimoor Cc: "gdb-patches\@sourceware.org" Subject: Re: Improving GDB's mechanism to check if function is GC'ed References: <556DB1BB.50601@codesourcery.com> Date: Wed, 10 Jun 2015 08:54:00 -0000 In-Reply-To: <556DB1BB.50601@codesourcery.com> (Taimoor's message of "Tue, 2 Jun 2015 18:38:03 +0500") Message-ID: <86eglkeyfw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00167.txt.bz2 Taimoor writes: Hi Taimoor, I happen to have to some time today to read your patch, here are my comments below, > > Current Problem > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > We are currently using GDB to debug Nucleus based bare-metal system > that also allows to dynamically load and unload Nucleus process > modules during system execution. > We currently load symbols of a modules using add-symbol-file whenever > a module is loaded at runtime. It is very common to have functions at > address 0x0 in debug information and then lowpc in symbol table to be > non-zero as it depends on section addresses given in add-symbol-file > command. GDB just uses some heuristics to determine whether the function is GC'ed by linker, so they may not be perfect. However, GDB doesn't support Nucleus, so it isn't a valid case to me. Do we have other cases that we add-symbol-file in which function address is at 0x0 on platforms GDB supports? If the problem only exists on Nucleus, I am afraid I don't agree with accepting this change, because GDB doesn't support Nucleus. Sorry. > > Possible Solution > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > * Modify GC checking mechanism to mark any function GC'ed using above > mentioned mechanism only if objfile is not dynamically loaded. So, for > any function with address 0x0, it'll be marked GC'ed only if lowpc is > not zero and objfile is main symbol file. > > For this I have made following modifications in if condition: > > if (address =3D=3D 0 && address < lowpc > && (objfile->flags & OBJF_MAINLINE)) > { > > I have regression tested this change and it seems to work fine. > Only downside that it is possible (though not common) to load main > symbol file using add-symbol-file command. In that case, GDB will not > check for GC'ed functions. In this way, GDB doesn't ignore the GC'ed function from the dynamically loaded objects, which is a regression to me. --=20 Yao (=E9=BD=90=E5=B0=A7)