From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5679 invoked by alias); 2 Oct 2008 10:36:15 -0000 Received: (qmail 5670 invoked by uid 22791); 2 Oct 2008 10:36:14 -0000 X-Spam-Check-By: sourceware.org Received: from cust198-202.dsl.versadsl.be (HELO mail.freepascal.org) (62.166.198.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Oct 2008 10:35:29 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.freepascal.org (Postfix) with ESMTP id 4B585B744E; Thu, 2 Oct 2008 12:34:10 +0200 (CEST) Received: from mail.freepascal.org ([127.0.0.1]) by localhost (idefix.wisa.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKKVeODcbI8a; Thu, 2 Oct 2008 12:34:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.freepascal.org (Postfix) with ESMTPS id E0744B7291; Thu, 2 Oct 2008 12:34:05 +0200 (CEST) Date: Thu, 02 Oct 2008 10:36:00 -0000 From: =?ISO-8859-15?Q?Dani=EBl_Mantione?= To: FPC Core Developer List cc: gpc@gnu.de, gdb-patches@sourceware.org Subject: Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation In-Reply-To: <00a101c9246e$22ebc8d0$68c35a70$@u-strasbg.fr> Message-ID: 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> <00a101c9246e$22ebc8d0$68c35a70$@u-strasbg.fr> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="663809-437423785-1222943645=:13206" 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/msg00048.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --663809-437423785-1222943645=:13206 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-length: 2990 Op Thu, 2 Oct 2008, schreef Pierre Muller: > 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:=1;' line. No, I didn't try to compile this. >> So each procedure context can redefine identifiers. >> >> Inside sub_procedure, the symtablestack will look like: >> >> 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 > 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. Correct. > Thus main_function. is not allowed > at least not for versions <= 2.2.0. > Did that change in 2.2.2? No, if this identifier is hidden in a local symtable as function result, you have to use my_program.main_function. >> 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 ... I don't think it needs to. unit_a, unit_b and unit_c are valid Pascal identifiers inside the symbol table of my_program. It should be possible to generate debug information for these identifiers. If GDB can handle sub_procedure as member of main_procedure, it should be able to handle "a" as member of unit_a, this is the same situation, I think? > In stabs, I believe that there is no information on that... > Does dwarf have something about this? Stabs is too limited for this. Dwarf could handle the full Pascal language, but it needs to be implemented in both debugger and compiler. > Of course, we could try to demangle the assembler labels used > to extract unit name, but I seem to remember that, at least for > Free Pascal, that mangling scheme is version dependent, which > will not simplify things :( Demangling should not be done at all, since the choice of the mangled name is at the discretion of the compiler. The ppu contains the correct mangled name for a certain procedure, but it is not guaranteed that you can go the other way. If the mangled name becomes too long (imagine a procedure with 100 parameters), the compiler starts using CRC checksums as mangled name, you can never parse this. All information the compiler has available is inside the ppu and the debug information is generated from it. We should simply place anything GDB needs into the debug information. > I also vaguely remember that GPC did not, at least for a > while, add anything to the procedure/function names > declared in the interface part of units, as in C language. This is correct, but making GDB support it correctly should have no negative impacts for GPC. Daniël --663809-437423785-1222943645=:13206--