From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8404 invoked by alias); 28 Feb 2014 17:57:19 -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 8395 invoked by uid 89); 28 Feb 2014 17:57:18 -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; Fri, 28 Feb 2014 17:57:16 +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 s1SHv9ht019390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Feb 2014 17:57:11 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 s1SHv8tJ017035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Feb 2014 17:57:09 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: <20140228163339.GC4860@adacore.com> References: <20140228163339.GC4860@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 28 Feb 2014 17:57:00 -0000 Message-ID: <1393610228.3893.49.camel@cslin101.csunix.comp.leeds.ac.uk> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-UOL-RateLimit: userRateLimit[scpmw@leeds.ac.uk,1.630480388906769,1393610231656] X-SW-Source: 2014-02/txt/msg00072.txt.bz2 Joel Brobecker wrote: > > We recently added DWARF output support to GHC, the main Haskell > > compiler. However, GDB doesn't seem to respect the function names we > > output as DWARF debug info and instead falls back to the symbol names. > > My understanding is that this is due to the DWARF source language ID > > we emit isn't recognized by GDB. Is this correct and, if so, how do we > > remedy the situation? > > I am wondering if your issue might go deeper than just recognizing > the language, but instead actually implement haskell support within > GDB. Hard to tell without more details of what's going on. Perhaps > a copy/past of a debugger sessions, annotated with what you would > have expected would help give you more details. https://ghc.haskell.org/trac/ghc/ticket/3693#comment:44 Here's a (short) example session. There are actually two problems here: #2 0x00000000004047a0 in Main_zdwfibzuerr_info () at stack-trace.hs:7 This is the issue Johan was talking about: We get the scrambled symbol table name, even though we have a complete .debug_info record: <1><37f>: Abbrev Number: 2 (DW_TAG_subprogram) <380> DW_AT_name : fib_err <388> DW_AT_MIPS_linkage_name: Main_zdwfibzuerr_info <39e> DW_AT_external : 255 <39f> DW_AT_low_pc : 0x4041c8 <3a7> DW_AT_high_pc : 0x40422e Which we would expect to result in the more useful "fib_err" getting shown. The actual story here seems to be that the linkage name overwrites the proper name, which from reading the source seems to be a language-specific decision? (Note: Yes, the addresses don't match, different compilation, sorry) Wile we're at it, here's another issue we are struggling with: #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. Greetings, Peter Wortmann