From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101673 invoked by alias); 17 Jan 2018 17:17:22 -0000 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 Received: (qmail 101529 invoked by uid 89); 17 Jan 2018 17:17:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=customer X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jan 2018 17:17:19 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id D57AB81C18 for ; Wed, 17 Jan 2018 18:17:16 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAGx6EGZEn-o for ; Wed, 17 Jan 2018 18:17:16 +0100 (CET) Received: from Xaviers-MacBook-Pro.local (unknown [194.98.77.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id BEF06818D7 for ; Wed, 17 Jan 2018 18:17:16 +0100 (CET) From: Xavier Roirand Subject: [RFC] expected behavior for "bt" command used with "set language ..." ? To: gdb-patches@sourceware.org Message-ID: Date: Wed, 17 Jan 2018 17:17:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00352.txt.bz2 Hello, While working on a customer issue, I've faced a (weird ?) behavior that exists in GDB since the beginning (as far as I can go back in the archives) when displaying frame arguments with a language manually set by the user. I'm wondering if this behavior is the right one or if we have to enhance it, thus this email. In the following example, C & Ada are used to explain the case but any other languages may be used, the only requirement here is two have a program using mixed languages with a function written in language A calling a function written in language B. Notice that, in order to see the behavior, you have to set print frame-arguments to all instead of scalar (default). This setting let the "bt" command show details on each frame arguments rather than ... in some cases. Imagine a program where an Ada procedure calls a C function: src.c: void break_me (void) {} pck.ads: [...] package Pck is procedure Stop_Ada; procedure Call_Me (U: in out Unbounded_String); end Pck; pck.adb: package body Pck is procedure C_Break_Me; pragma Import (C, C_Break_Me, "break_me"); procedure Stop_Ada is begin null; end Stop_Ada; procedure Call_Me (U: in out Unbounded_String) is begin C_Break_Me; Stop_Ada; end Call_Me; end Pck; Here, the Call_Me (Ada) procedure calls the c_break (C) function Let's start a GDB session: (gdb) set language c (gdb) set print frame-arguments all (gdb) b break_me Breakpoint 1 at 0x402518: file src.c, line 4. (gdb) r Starting program: foo Breakpoint 1, break_me () at src.c:4 4 } Now let's show the backtrace: (gdb) bt #0 break_me () at src.c:4 #1 0x0000000000402533 in pck.call_me (u= @0x7fffffffe248: {_parent = {_parent = {_tag = 0x429580 }}, reference = 0x644010}) at pck.adb:12 #2 0x0000000000402750 in foo_r112_041 () at foo_r112_041.adb:7 (gdb) As you can see, the U parameter in pck.call_me is weird. GDB uses C printing function because it is using current language which is set to C. In some cases, with current language set to C++, printing backtrace with Ada functions/parameters may lead to GDB crash. When I say using C printing function or Ada printing function it's more related to value_cast function which does not know about current frame language but only about current global language. The question I have based on what this session shows is: When printing one frame arguments, should we do it using the language of the frame, and it may be different for each frame in a single "bt" command or should we leave things as they are, and possibly allow the "bt" command to display weird values for frame arguments or even worse, crash GDB because the user set language manually so he has to know what he's doing ? If first proposal is preferred, then using the above example, the break_me frame arguments would be printed using C printing function from GDB and the pck.call_me frame arguments would be printed using Ada printing function from GDB. This would be printed like this: #0 break_me () at src.c:4 #1 0x0000000000402533 in pck.call_me (u=(reference => 0x644010)) at pck.adb:12 #2 0x0000000000402750 in foo_r112_041 () at foo_r112_041.adb:7 This can be implemented for instance by saving the current language & mode before printing frame arguments and restored after. This can also probably be done by adding frame language parameter to a lot of language specific functions for each language and finally to value_cast but this second solution requires a huge amount of work. Regards.