From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28841 invoked by alias); 2 Oct 2008 09:07:17 -0000 Received: (qmail 28590 invoked by uid 22791); 2 Oct 2008 09:07:14 -0000 X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Oct 2008 09:06:34 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.2/jtpda-5.5pre1) with ESMTP id m9296HTF075260 ; Thu, 2 Oct 2008 11:06:21 +0200 (CEST) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402::142]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id m9296Grj006718 ; Thu, 2 Oct 2008 11:06:16 +0200 (CEST) Received: from d620muller (www-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id m9296GVk072204 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Thu, 2 Oct 2008 11:06:16 +0200 (CEST) (envelope-from muller@ics.u-strasbg.fr) From: "Pierre Muller" To: "=?iso-8859-1?Q?'Dani=EBl_Mantione'?=" , "'FPC Core Developer List'" Cc: , References: <20080930152757.GC23135@adacore.com> <002601c92313$27d06790$777136b0$@u-strasbg.fr> <20080930170648.GI3811@adacore.com> <20080930173837.GA959@caradoc.them.org> <20081001011534.GA3665@adacore.com> <003201c92399$3207f300$9617d900$@u-strasbg.fr> <20081001163945.GI3665@adacore.com> In-Reply-To: Subject: RE: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation Date: Thu, 02 Oct 2008 09:07:00 -0000 Message-ID: <00a101c9246e$22ebc8d0$68c35a70$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::156]); Thu, 02 Oct 2008 11:06:21 +0200 (CEST) X-Virus-Status: Clean 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: 2008-10/txt/msg00045.txt.bz2 Hi Daniel, > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Dani=EBl Mantione > Envoy=E9=A0: Thursday, October 02, 2008 8:43 AM > =C0=A0: FPC Core Developer List > Cc=A0: Pierre Muller; gpc@gnu.de; gdb-patches@sourceware.org > Objet=A0: Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc > bound calculation >=20 >=20 >=20 > Op Wed, 1 Oct 2008, schreef Joel Brobecker: >=20 > > The answer to the question above lies in the Pascal parser. But when > > there are homonyms, how do you specify in your program exactly which > > one you mean? And does GDB provide the same method for distinguishing > > these homonyms? > > > > (need to relearn Pascal one of these days...) >=20 > Pascal has a stack based symbol resolving (we call it the symtablestack > in > the compiler). For example take for example the following program: >=20 > program my_program; >=20 > uses unit_a,unit_b,unit_c; >=20 > var a:integer; >=20 > procedure main_procedure; >=20 > var a:integer; >=20 > procedure sub_procedure; >=20 > var a:integer; >=20 > begin > a:=3D1; > main_procedure.a:=3D1; > my_program.a:=3D1; > unit_a.a:=3D1; > unit_b.a:=3D1; > unit_c.a:=3D1; > end; >=20 > begin > end; Daniel, did you really try to compile this? Both Free Pascal 1.0.10 and 2.2.0 fail to compile on the 'main_procedure.a:=3D1;' line. =20 > So each procedure context can redefine identifiers. >=20 > Inside sub_procedure, the symtablestack will look like: >=20 > unit_a > unit_b > unit_c > my_program > main_procedure > sub_procedure The stack is correct, but the problem is that if main_procedure would be a function, then main_function would be usable inside sub_procedure=20 either as a nested call by adding an explicit main_function() even if the function has no parameters, or to set the return value of main_function function. Thus main_function. is not allowed=20 at least not for versions <=3D 2.2.0. Did that change in 2.2.2? =20=20 > When searching for a symbol, the compiler will search the symbol tables > bottom to top, starting at sub_procedure, ending at unit_a, the first > symbol found is used. GDB would need to implement the same behaviour in > it's Pascal mode. The main current problem is that GDB knows nothing about the used or loaded units ... In stabs, I believe that there is no information on that... Does dwarf have something about this? Of course, we could try to demangle the assembler labels used=20 to extract unit name, but I seem to remember that, at least for=20 Free Pascal, that mangling scheme is version dependent, which=20 will not simplify things :( I also vaguely remember that GPC did not, at least for a=20 while, add anything to the procedure/function names declared in the interface part of units, as in C language. This had the big drawback of preventing to have the=20 same global function/procedure in two different units that is normally allowed according to pascal syntax. Could someone from the GPC development team tell us if this limitation is still in place or if it has been lifted? Thanks for the answers, Pierre Muller Pascal language support maintainer for GDB