From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 489 invoked by alias); 10 Oct 2013 15:30:41 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 472 invoked by uid 89); 10 Oct 2013 15:30:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Oct 2013 15:30:39 +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.14.4/8.14.4) with ESMTP id r9AFUUmd021935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Oct 2013 11:30:38 -0400 Received: from barimba (ovpn-113-128.phx2.redhat.com [10.3.113.128]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9AFUTib011466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 10 Oct 2013 11:30:29 -0400 From: Tom Tromey To: Simon Sobisch Cc: gdb@sourceware.org Subject: Re: Question about getting GNU Cobol work with GDB References: <525328B4.3020405@web.de> <5255D935.30609@web.de> Date: Thu, 10 Oct 2013 15:30:00 -0000 In-Reply-To: <5255D935.30609@web.de> (Simon Sobisch's message of "Thu, 10 Oct 2013 00:31:17 +0200") Message-ID: <87k3hl87oq.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-10/txt/msg00043.txt.bz2 >>>>> "Simon" == Simon Sobisch writes: Simon> GNU Cobol (formerly OpenCOBOL) translates COBOL to C (compiling Simon> it with GCC later on). We try to use GDB as debugging frontend Simon> but are unsure how some points can be reached without actually Simon> patching the GDB (if it's possible at all). Simon> - let the programmer see only the COBOL source, not the C source, Simon> while stepping I agree with the other poster who suggested #line. Simon> - let the programmer view/change/... COBOL variables (there is a Simon> mapping like you can see above) I don't think this is doable with your current translation approach. The simplest way to get this information into gdb is to write out DWARF from your compiler. DWARF lets you specify the names of variables and where they live. However, I think there's no good way to write out DWARF in the C code your front end generates. *Maybe* it can be done in a gross way by emitting lots of 'asm' statements, but I am not sure whether this can be made to work without a lot of exertion. This sort of thing is one reason that it is generally better to write a GCC front end than to write a translator. This is easier than it sounds, but of course you probably have reasons for wanting to do C translation. At that point you'll want to write the gdb language support... Simon> - set breakpoints within the COBOL source I think #line may help here as well, at least for "file:line" breakpoints. I don't remember enough COBOL to know whether there are named procedures. If there are then those will face the same conceptual problem as variables: if the COBOL->C name mapping requires some transformation, then users won't have a way to use to the name from their COBOL source. Tom