From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16986 invoked by alias); 5 Mar 2014 18:06:28 -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 16968 invoked by uid 89); 5 Mar 2014 18:06:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mhost02c.leeds.ac.uk Received: from mhost02c.leeds.ac.uk (HELO mhost02c.leeds.ac.uk) (129.11.76.154) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 05 Mar 2014 18:06:25 +0000 Received: from mhost04h.leeds.ac.uk (mhost04h-smtps.leeds.ac.uk [129.11.77.129]) by mhost02c.leeds.ac.uk (8.14.4/8.14.4) with ESMTP id s25I6IqN018200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Mar 2014 18:06:19 GMT Received: from [129.11.146.101] (cslin101.csunix.comp.leeds.ac.uk [129.11.146.101]) (authenticated bits=0) by mhost04h.leeds.ac.uk (8.14.4/8.14.4) with ESMTP id s25I6HoX010402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Mar 2014 18:06:17 GMT Subject: Re: Making GDB recognize the Haskell DWARF source language ID From: Peter Wortmann To: Joel Brobecker Cc: Johan Tibell , gdb In-Reply-To: <20140305151609.GP4860@adacore.com> References: <20140228163339.GC4860@adacore.com> <1393610228.3893.49.camel@cslin101.csunix.comp.leeds.ac.uk> <20140305151609.GP4860@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 05 Mar 2014 18:06:00 -0000 Message-ID: <1394042775.9074.28.camel@cslin101.csunix.comp.leeds.ac.uk> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-UOL-RateLimit: userRateLimit[scpmw@leeds.ac.uk,0.025345532238130044,1394042779786] X-SW-Source: 2014-03/txt/msg00007.txt.bz2 On Wed, 2014-03-05 at 15:16 +0000, Joel Brobecker wrote: > > #1 0x0000000000694330 in ?? () at rts/Updates.cmm:57 > > > > What happens here is that 694330 gets derived correctly as the address > > to return to, but GDB actually seems to attempt to look up 69432f (= the > > address right in front) for display name and line number information. > > That might make sense for most compiled languages, but for GHC code, the > > space in front of return code pointers is an info table (= data). Hence > > GDB gets moderately confused when it can't find any information on it. > > > > So far we essentially hack around this by applying a suitable "offset" > > to line data as well as unwind information. That's why we have a source > > code pointer, and the stack trace doesn't simply stop at that point. But > > that's a rather crude solution, so any ideas would be appreciated. > > I'm not really sure in this case. The model seems odd - are you > returning outside of the function's code / block range, or do you > have data in the middle of your function code? Perhaps a language > hook to provide flexibility in the offset... Data in the middle of function code is about right - the idea is that the return pointer doubles as frame layout description for garbage collection. Here's roughly what our assembly looks like: .text .align 8 .quad 1 .loc 1 49 1 /* hack so GDB still shows line info */ .quad 35 stg_marked_upd_frame_info: .loc 1 49 1 movq 8(%rbp),%rax movq 8(%rax),%rcx testq $7,%rcx Note the ".quad"s that make up the info table for the function. If I read the GDB code correctly, one of the sources of the problem is that the get_frame_address_in_block function applies a "-1" offset for "NORMAL_FRAME". The comment seems to suggest that this is to work correctly with non-returning frames where the return pointer might be invalid. However for Haskell, code return locations are pushed explicitly, and decreasing it is guaranteed to land in no-man's-land. Greetings, Peter Wortmann