From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54432 invoked by alias); 7 May 2015 17:06:35 -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 54417 invoked by uid 89); 7 May 2015 17:06:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 07 May 2015 17:06:33 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t47H6WfQ002592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 7 May 2015 13:06:32 -0400 Received: from host1.jankratochvil.net (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t47H6Snn003403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 May 2015 13:06:31 -0400 Date: Thu, 07 May 2015 17:06:00 -0000 From: Jan Kratochvil To: Alexandre Oliva Cc: Phil Muldoon , gdb@sourceware.org Subject: Re: compile: objfiles lifetime UI Message-ID: <20150507170628.GA12816@host1.jankratochvil.net> References: <20150429135735.GA16974@host1.jankratochvil.net> <55420463.10400@redhat.com> <20150430105349.GA6260@host1.jankratochvil.net> <20150506122637.GA21147@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00009.txt.bz2 On Thu, 07 May 2015 04:53:37 +0200, Alexandre Oliva wrote: > However, it's not clear where to draw the line when a (pointer to a) > string (literal) is passed to some inferior function. Technically, it > is an escaping pointer, but printf won't save it, whereas add_to_list > will. So we don't want it to be an error, at most a warning. OK, you are right that printf() would be the most common false positive. printf() could be excepted but that is not much foolproof solution. > But then, wouldn't we be better served by teaching users to use strdup > in gdb-compile snippets when they wish to get strings preserved (and > permanently leaked) in the inferior? If GDB wants to at least catch up with LLDB then no. In LLDB it just works. And personally I do not think "teaching users" works anymore, if it does not work out of the box the user will just use a better tool. ------------------------------------------------------------------------------ The most simple case in LLDB just works: 1 #include 2 char *a; 3 int main(void) { -> 4 puts(a); 5 return 0; } (lldb) p a="foo" (char *) $0 = 0x00007ffff7ff5000 "foo" (lldb) c Process 13050 resuming foo Process 13050 exited with status = 0 (0x00000000) ------------------------------------------------------------------------------ This is because LLDB always keeps the last 'injected code' mapped. But it is only the last 'injected code' so a more complicated case no longer works: ------------------------------------------------------------------------------ 1 #include 2 char *a,*b; 3 int main(void) { -> 4 puts(a); puts(b); 5 return 0; } (lldb) p a="foo" (char *) $0 = 0x00007ffff7ff5000 "foo" (lldb) p b="bar" (char *) $1 = 0x00007ffff7ff5000 "bar" (lldb) c Process 13135 resuming bar bar Process 13135 exited with status = 0 (0x00000000) ------------------------------------------------------------------------------ For that case one already needs to read 'help print' where LLDB has: User defined variables: You can define your own variables for convenience or to be used in subsequent expressions. You define them the same way you would define variables in C. If the first character of your user defined variable is a $, then the variable's value will be available in future expressions, otherwise it will just be available in the current expression. So in LLDB one can do: ------------------------------------------------------------------------------ 1 #include 2 char *a,*b; 3 int main(void) { -> 4 puts(a); puts(b); 5 return 0; } (lldb) p char $a[]="foo";a=$a (char *) $0 = 0x00007ffff7ff5030 "foo" (lldb) p char $b[]="bar";b=$b (char *) $1 = 0x00007ffff7ff5040 "bar" (lldb) c Process 13260 resuming foo bar Process 13260 exited with status = 0 (0x00000000) ------------------------------------------------------------------------------ Originally I wanted to make it even more automatic than the LLDB's $-variables but that looks as not really possible by that IR analysis. So personally I think GDB/GCC should do the same as LLDB so that the users are not forked from how they are already used to LLDB. Technically GCC could put the $ variables into some new section? Jan